[nuttx] Getting started, IPv6 on sub 1GHz B-L475E-IOT01A

[[e-mail] [nuttx]]

Hi all,


I'm getting started with NuttX here and have been struggling a little getting my development environment set up correctly.


In the end I went with a Docker container which I've brought up to date and pushed into GitHub here


https://github.com/DynamicDevices/docker-nuttx https://github.com/DynamicDevices/docker-nuttx



I was following some instructions Alan put me onto here


http://reclonelabs.com/building-nuttx-in-ubuntu-from-scratch/ http://reclonelabs.com/building-nuttx-in-ubuntu-from-scratch/



So I've successfully built up an image for STM32F4-Discovery and I've pushed pre-built containers for both toolchain and the NuttX image to the Docker Hub here


https://hub.docker.com/r/dynamicdevices/nuttx/ https://hub.docker.com/r/dynamicdevices/nuttx/



So now what I'd like to do is built for the B-L475E-IOT01A / STM32L4 Discovery kit IoT node


Can anybody point me to any instructions / configurations etc. on getting going with this?


Separately I'm aiming to put a demo on the Internet on IPv6 so has anybody had any success bridging the sub-GHz to an IPv6 tunnel?


Thanks!


Alex

[[e-mail] [nuttx]]

Great! I am glad that you are B-L475E-IOT01A. It is a very cool board. I have not been as enthused about a board since the STM32F4 Discovery was first released.

There is no tutorial for that board specifically, but everything that you have done with the STM32F4 Discovery should apply. I think that the only difference you will encounter is in that the ST-Linkv2 is a little never and support the mbed drag and drop interface (which I never used). I used the STMico ST-Link Flush Utility for all programming.

There is a README at configs/b-l47e-iot01a/README.txt that describes the port.

There is no tunneling logic in the stack now. But I am very interested in this and would like to help you to extend the IPv6 support for tunneling. There is all the hooks in place now -- I am thinking of routing table support, but nothing in the IPv6.

There is a good implementation of IP forwarding that I have in place. So this would permit you to, say, set up the 802.11 wireless and forward packets to and from individual spirit radios in, say, a star configuration and the open internet. That does not require tunneling since it is just IPv6 routing. That is in place now and tested in a few configurations.

This is one of my objectives: IP forwarding between packet radios and the Internet.


Greg

Greg


Greg

[[e-mail] [nuttx]]

One problem with the B-L475E-IOT01A is that its 802.11 wireless is packaged as a serial module. The network stacks are built into the wireless part and, hence, they cannot integrate with the NuttX stack.


There is support for external stacks (CONFIG_NET_USRSOCK), but in order to use the external stacks, you have to disable the internal stacks preventing you from using 6LoWPAN and talking with the radios. So I do not think the 802.11 wireless module will be usable in any integrated way with the Spirit1 radios.


An alternative that I considered was to use the B-L475E-IOT01A for the endpoint nodes in a star configuration, but use an STM32 Nucleo board as the hub with the X-NUCLEO-IDS01A5 shield that has the Spirit1 SPSGRF-915 on it. Then, for initial testing, you could use Ethernet from the Nucleo board to interface with a host PC.


Greg

[[e-mail] [nuttx]]

Hi Greg,


Very interesting. Thanks for coming back to me so quickly.


Yes, as I was saying to Alan I too am hugely enthused about this board. I've been waiting for a decent sub-GHz IPv6 capability for many many years. We've had huge problems with 802.15.4 meshing in our IoT sensor devices, in part to to the range and wet-body issues and I think this could really be a breakthrough.


I am a complete newbie to ST. I've used pretty much everything else but not them :)) I'm mostly on NXP Kinetis parts for these kind of IoT sensor devices nowadays, with i.MX6 for the higher end Linux capable machines. I see those two things working well together.


I am looking forward to getting some life out of these - I'll take a look at those details you sent thanks, I'll try to write up where I get to with this, and if we have the opportunity to work to getting bridging going to demo some IoT IPv6 stuff I think that would be awesome! I will definitely make some time somewhere for that.


Cheers,


Alex

[[e-mail] [nuttx]]

Greg,

I've had similar trouble using the CC3200. I don't particularly enjoy working with these encapsulated serial modules.


What are the chances of using the Spirit1 with a Linux capable board as the hub of the star topology?


I suppose a similar question is, how compatible is the NuttX 6LowPan implementation with the Linux kernel 6LowPan (understanding there would presumably be a Spirit1 Linux 6LowPan driver needed?


Cheers,


Alex

[[e-mail] [nuttx]]

Does Linux work with generic packet radios? Or just IEEE 802.15.4 radios? The Spirit1 is NOT IEEE 802.15.4 compatible. You won't be able to wire an IEEE 802.15.4 driver for it; I am not sure what the capability of the Linux 6LoWPAN driver is or if and how it interacts with non-IEEE 802.15.4 radions.


The probability of compatibility is low.


Contiki implements 6LowPAN for the Spirit1 radios but NuttX is not compatible with Contiki either. Contiki fakes an IEEE 802.15.4 radio and carries a fake IEEE 802.15.4 MAC header at the beginning of the Spirit1 payload. Nothing in that payload has anything to do with the radio; it is just wasteful overhead (25 bytes is reserved for the header). But it does let Contiki process the payload portion was though it were a complete, very small IEEE802.15.4 packet.


I think they do that only to keep their 6LoWPAN implementation as simple as possible.


NuttX does not do that, it talks 6LoWPAN directly with the Spirit1 radio and does not require a IEEE 802.15.4 header in the payload; the entire packet payload is available for the application. This is much more efficient but also much more work for me. So the NuttX 6LoWPAN cannot be used with the Contiki 6LoWPAN. And probably not with Linux either.


For a hub and the MRF24J40, I am using a 300MHz Cortex-M7 SAMV71-XULT and SAME70-Xplained and a Click Shield with the MRF24J60 Click Bee on it. Very high performance.


I have a Spirt1 shield on order from China and intend to use those same platforms as the hub with that shield as well.


The STM32F7 Disco (which is worse performance) has Arduino connectors as do all of the SAMA5Dx boards.


Greg

[[e-mail] [nuttx]]

Sorry about all of the typos. I type quite rapidly and my hands go into automatic and complete words on my behalf without my mental intervention. Like "wire" instead of "write". "now" often turns into to "not" which is really confusing.


Anyway...


So my vision for PC connectivity is not to have 6LoWPAN running on the PC, but rather to have a higher powered hub that captures and forwards all radio traffic. The SAMv7 boards that I mention also have Ethernet (as do the others).


The Spirit1 hub does "route over" routing: If fully expands the fragmented, compressed Spirit1 packets into full, standard IPv6 packets, It then looks at the destination IP address; if the destination address is another radio node then the packet is re-compressed and forwarded to that radio. If Ethernet is available, however, it can also forward standard IPv6 packets to/from the host from/to any node in the PAN.


The host then does not need to be bothered with 6LoWPAN at all. It sends and receives standard, Ethernet IPv6 packets that are fragmented, compressed, and forwarded to radio nodes. Similarly, frames from the radio nodes are reassembled to standard IPv6 packets that can be forwarded to the host via Ethernet.


So full host operability is supported with a standard network interface and nothing special is required on the host. The host can be any kind of PC, not just Linux. It could even be a router! No limitations at all!


That is a really, good, portable solution! It has product value!


At this point, I have not demonstrated the full end-to-end PC/radio packet transfer. All of the pieces are in place but there are things that have not been verified. I will do that when I have all of the hardware in hand.


Greg

[[e-mail] [nuttx]]

I added some slides to illustrate this better in the group Files area at: https://groups.yahoo.com/neo/groups/nuttx/files called starhub.pdf.

[[e-mail] [nuttx]]

Hi Greg,

Thanks for going into the detail...


"The host then does not need to be bothered with 6LoWPAN at all. It sends and receives standard, Ethernet IPv6 packets that are fragmented, compressed, and forwarded to radio nodes. Similarly, frames from the radio nodes are reassembled to standard IPv6 packets that can be forwarded to the host via Ethernet."


That sounds a great way of doing things. Much easier to deal with....


Cheers!


Alex

[Sebastien Lorquet [e-mail] [nuttx]]

hello

I am also interested in packet radio from a ham radio / hamnet perspective.

I am currently finishing this:

https://github.com/f4grx/hn70ap

This will be a board with ethernet, a rfm26 or rf4463 module, and a
si4463 with separate RX and TX RF lines for some experimentation on the
RF side.

The use case for this board will be to study the implementation of
extensions to the hamnet network. It is a kind of packet radio access
point. But it can also be used for IoT things.

Some declinations can be made later to support the SPSGRF modules, but
it's not the primary goal (I will try to add some generic extensions
capabilities).

The primary goal is instead to write a working universal driver for the
si4463 without using silabs tools to configure the chip.

I am attaching the current routing status. I will be able to distribute
PCBs to would be builders. I can pre-solder QFNs if required.

Sebastien

Post by ***@gmail.com [nuttx]
Hi Greg,
Thanks for going into the detail...
"The host then does not need to be bothered with 6LoWPAN at all. It
sends and receives standard, Ethernet IPv6 packets that are
fragmented, compressed, and forwarded to radio nodes. Similarly,
frames from the radio nodes are reassembled to standard IPv6 packets
that can be forwarded to the host via Ethernet."
That sounds a great way of doing things. Much easier to deal with....
Cheers!
Alex

[Sebastien Lorquet [e-mail] [nuttx]]

and because yahoo groups are not welcome:

routing status : http://www.mirari.fr/1TvM

schematic : http://www.mirari.fr/Wv1S

adding a spsgrf footprint looks doable.

sebastien

[Attachment(s) <#TopText> from Sebastien Lorquet included below]
hello
I am also interested in packet radio from a ham radio / hamnet
perspective.
https://github.com/f4grx/hn70ap
This will be a board with ethernet, a rfm26 or rf4463 module, and a
si4463 with separate RX and TX RF lines for some experimentation on
the RF side.
The use case for this board will be to study the implementation of
extensions to the hamnet network. It is a kind of packet radio access
point. But it can also be used for IoT things.
Some declinations can be made later to support the SPSGRF modules, but
it's not the primary goal (I will try to add some generic extensions
capabilities).
The primary goal is instead to write a working universal driver for
the si4463 without using silabs tools to configure the chip.
I am attaching the current routing status. I will be able to
distribute PCBs to would be builders. I can pre-solder QFNs if required.
Sebastien

Post by ***@gmail.com [nuttx]
Hi Greg,
Thanks for going into the detail...
"The host then does not need to be bothered with 6LoWPAN at all. It
sends and receives standard, Ethernet IPv6 packets that are
fragmented, compressed, and forwarded to radio nodes. Similarly,
frames from the radio nodes are reassembled to standard IPv6 packets
that can be forwarded to the host via Ethernet."
That sounds a great way of doing things. Much easier to deal with....
Cheers!
Alex

[Alan Carvalho de Assis [e-mail] [nuttx]]

Hi Alex,

The reclonelabs.com tutorials were developed by Jeff not me! :-)

In fact ST engineers should have used SDIO for communication with WiFi
module. This way NuttX could to take control over it.

It should be nice to have a board (i.e. Raspi) with Linux to interface
with 6LoWPAN network of NuttX devices. But AFAIK nobody added support
for 6LoWPAN on SPIRIT1 in the Linux kernel. I found a question about
it here:

https://community.st.com/thread/40403-spi-driver-for-spirit1-module-on-x86-platform

So currently all nodes need to be running NuttX.

BR,

Alan

Post by ***@gmail.com [nuttx]
Greg,
I've had similar trouble using the CC3200. I don't particularly enjoy
working with these encapsulated serial modules.
What are the chances of using the Spirit1 with a Linux capable board as the
hub of the star topology?
I suppose a similar question is, how compatible is the NuttX 6LowPan
implementation with the Linux kernel 6LowPan (understanding there would
presumably be a Spirit1 Linux 6LowPan driver needed?
Cheers,
Alex

[[e-mail] [nuttx]]

I don't know if Jayaram Matta complete this or not. But now I am 100% certain that it would not be compatible with the NuttX implementation. He wrote "I want to add support for 6LoWPAN over 802.15.4 to the Jayaram Matta Linux kernel". The Spirit1 is NOT an IEEE 802.15.4 radio and cannot support the requirements of IEEE 802.15.4.

I mentioned that Contiki solved this by adding a 25 byte "fake" IEEE 802.15.4 at the beginning of each payload. With this (and something Adam calls the null RDC), Contiki was able to make the Spirit1 radio look enough like an IEEE 802.15.4 radio for 6LoWPAN.

NuttX does NOT use any fake "IEEE 802.15.4 header" but, instead, uses the native radio MAC layer. Thus, the NuttX Spirit1 6LoWPAN will never be able to communicate with either Contiki or any radio that "support[s] over IEEE802.15.4"

Greg

[Alan Carvalho de Assis [e-mail] [nuttx]]

Yes, I think for hardware that is not really 802.15.4 (2.4GHz) it
doesn't make sense to keep the IEEE 802.15.4 header. It will just be a
not necessary overhead.

BR,

Alan

Post by ***@yahoo.com [nuttx]
I don't know if Jayaram Matta complete this or not. But now I am 100%
certain that it would not be compatible with the NuttX implementation. He
wrote "I want to add support for 6LoWPAN over 802.15.4 to the Jayaram Matta
Linux kernel". The Spirit1 is NOT an IEEE 802.15.4 radio and cannot support
the requirements of IEEE 802.15.4.
I mentioned that Contiki solved this by adding a 25 byte "fake" IEEE
802.15.4 at the beginning of each payload. With this (and something Adam
calls the null RDC), Contiki was able to make the Spirit1 radio look enough
like an IEEE 802.15.4 radio for 6LoWPAN.
NuttX does NOT use any fake "IEEE 802.15.4 header" but, instead, uses the
native radio MAC layer. Thus, the NuttX Spirit1 6LoWPAN will never be able
to communicate with either Contiki or any radio that "support[s] over
IEEE802.15.4"
Greg