Thanks!
I’ll connect the UART GPIO’s, in fact, i was also thinking about HWFC in that trajectory - that should make the UART much more stable, at least at higher bitrates. (And i’ll try lower baudrate + openvisualizer too)
I set the bitrate to 19200, connected the NRF board using GPIO pins, and i changed to the patched openvisualizer version and tried the openv-serial to test the link: With packet size 20 ( openv-serial --baudrate 19200 --port /dev/ttyUSB0 --verbose -l 20) I get 100% throughput, but above 20 i never get 100% sucess.
I would have to get my hand on and nrd52840dk to reproduce… I only have nrf52840-mdk and this is my result on master:
USEMODULE="stdio_null openwsn_serial" BOARD=nrf52840-mdk make -C tests/pkg_openwsn flash term -j
openv-serial --port /dev/riot/tty-nrf52840-mdk
/home/francisco/.virtualenvs/openv/lib/python2.7/site-packages/paramiko/transport.py:33: CryptographyDeprecationWarning: Python 2 is no longer supported by the Python core team. Support for it is now deprecated in cryptography, and will be removed in the next release.
from cryptography.hazmat.backends import default_backend
Serial Tester Script...
Test Setup:
----------------
Iterations: 100
Packet length: 100
Echo timeout: 2
Test Progress:
[####################################] 100%
Test Statistics:
----------------
Pkts send: 100
Echo success: 100
Echo timeout: 0
Echo corrupted: 0
exiting...
Terminated
Note that this is with the openvisualizer patch, without it I get bad results. So I guess openwsn_serial/openvisualizer is flaky nrf52840. I’m sorry my initial test results came from a wrong base.
What is the significance of “flash term” in your make command? I notice when i do that i get a serial, and when i kill that terminal i can run (riot) openv-serial 100% But when i re-boot/reset the board openv-serial does not work anymore
No significance, Its just a habit of doing flash term all the time, but here only flash should be needed. After having the BOARD sit on my desk flashed (so cold boot), and also after reboot I get the same results. So it might be something with the dk.
Thanks for clarification!
The riot openvisualizer works better with the serial link. However, the root does not report any JRC with the riot openvisualizer - with old openvisualizer i could at least see the requests.
Changing branch to develop-RIOT i get to the point where openv-server report this:
`1:41:33 WARNING Probing motes: ['/dev/ttyACM0'] at baudrates ['19200']
11:41:33 SUCCESS Discovered serial-port(s): ['/dev/ttyACM0']
11:41:33 INFO extracting firmware definitions.
11:41:33 VERBOSE extracting firmware component names
11:41:33 VERBOSE extracting firmware log descriptions.
11:41:33 VERBOSE extracting 6top return codes.
11:41:33 VERBOSE extracting 6top states.
11:41:33 INFO starting RPC server
11:41:33 SUCCESS connected to broker (argus.paris.inria.fr) for mote on port: /dev/ttyACM0
11:41:38 SUCCESS Setting mote 2d2a as root
11:41:38 ERROR 2d2a [IEEE802154E] wrong state 1 in startSlot, at slotOffset 1
11:41:39 INFO registering DAGroot ae-46-83-2e-dd-17-49-38
11:44:33 VERBOSE New node: be53:2d94:edd:2250. Creating new OSCORE context in /home/EU/seblomqpe/.local/share/openvisualizer/oscore_context_be532d940edd2250.json.
11:44:33 VERBOSE received JRC join request
For a brief moment the root node seems to have scheduled a slot extra slot but that dissapears and the client still reports:
IEEE802154E sync: 0
6TiSCH joined: 0
NO RPL parent
So it seems client is unable to join
It seems like there is some kind of issue, can you open an ISSUE on github with your setup and means to reproduce?
I will do so. I brought two NRF 52840 dongles (Nordic) that i tried but after flashing the USB enumeration fails on my ubuntu 18.04 machine.
I am considering obtaining the NRF52840 MDK as a reference.
If you use the dongles use them with the UART gpio’s as the usb is not an USART pass through but native usb, in RIOT for those stdio_cdc_acm is used, but OpenWSN works only with USART.
I did some more digging into my problem on NRF DK and it seems my problems may stem from the nrf802154_radio.c together with my Zigbee network: If the “adress filtering” and “ack filtering” fails in isr_radio in nrf802154_radio.c “simply drop the frame and continue listening to incoming frames” - and IEEE802154.c in WSN will inhibit the serial between start/stop frame. I made a test handling this situation as a CRC error in nrf802154.c and then the serial stays on.
Hmm… does this mean we are not getting the IEEE802154_RADIO_INDICATION_RX_DONE when that happens?
Right. Those frames are just dropped - and serial is blocked until other frames arrives. This may not be significant since i think this is less likely in the root where serial is needed.
I activated RTT prints on my NRF boards and it seems like there are a lot of frames dropped due to CRC errors - unsure if this is due to changed timing due to the prints - but RTT itself should be pretty fast. For a reference i tried vanilla OpenWSN on my DK boards and it works with serial connection through the MCU so it does not seem like the serial is the problem.
One thing i noticed on OpenWSN is abscence of CoJP traffic - README.md for nrf 52840 has a notice saying “L2 Security is not supported” - file may be out of date since it mentions commenting out but now cjoin is a configuration option?
I activated RTT prints on my NRF boards and it seems like there are a lot of frames dropped due to CRC errors - unsure if this is due to changed timing due to the prints - but RTT itself should be pretty fast. For a reference i tried vanilla OpenWSN on my DK boards and it works with serial connection through the MCU so it does not seem like the serial is the problem.
That is not a valid test, since AFK OpenWSN is broken on the DK on OpenWSN vanilla, so it works because no 6TSCH stuff is going on.
One thing i noticed on OpenWSN is abscence of CoJP traffic - README.md for nrf 52840 has a notice saying “L2 Security is not supported” - file may be out of date since it mentions commenting out but now cjoin is a configuration option?
What README.md is this? Is it from openwsn-fw? In any case L2-Security in this case comes from the OpenWSN stack, and its disabled by default. You can enable it by adding USEMODULE += openwsn_iee802154e_security. But I wouldn’t add this extra module while everything else is not yet working.
Thanks for update!
L2 Security was WSN on NRF52840 - i notice that SW implementations of crypto are too slow on NRF to work with TiSCH - so it’s best left disabled as you suggest.
It’s very interesting that OpenWSN is “broken on the DK on OpenWSN vanilla”. I have setup the NRF 802.15.4 sniffer so i will continue look into this.