It is currently Sun Dec 17, 2017 3:55 pm




Post Reply  Page 1 of 2 [ 12 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Tue Sep 01, 2015 8:38 pm 

Joined: Tue Sep 01, 2015 8:31 pm
Posts: 24
Location: Paris, France
Hello,
I would like to post a question regarding DASH7 device nodes - what is the best ways of managing and provisioning them.

I am currently working on a cloud based service to control a large number of devices, an so far we have been observing LWM2M which goes over CoAP - pretty standardized and well documented protocol. Does something makes sense in DASH7 world (please note that I have a very limited knowledge on DASH7)?

If not, what would be the best way for a distant cloud server to register (with proper authentication) and then manage these devices?

Best regards,
Drasko


Offline
 Profile  
 
PostPosted: Wed Sep 02, 2015 2:00 pm 
Site Admin

Joined: Tue Jun 12, 2012 4:33 am
Posts: 25
Location: New York, NY
What is your opinion on CoAP? It uses UDP so it should be able to run on DASH7. But, someone will need to port the server app (what runs on the node) into OpenTag. That shouldn't be too hard. The problem is that I looked at this last time in 2012, and all the work on CoAP was using silly function like malloc. Give me a break! This is embedded! Maybe now there is a static version of CoAP.


Offline
 Profile  
 
PostPosted: Wed Sep 02, 2015 7:39 pm 

Joined: Tue Sep 01, 2015 8:31 pm
Posts: 24
Location: Paris, France
Quote:
What is your opinion on CoAP?

Well, it look like very sane, standardized (https://tools.ietf.org/html/rfc7252), well documented protocol with a lot of implementations in different languages. It looks to me like a best application layer protocol for IoT of all I have seen so far (I just started reading DASH7 spec, so I have no knowledge about this one yet).

But more importantly, LWM2M (https://www.youtube.com/watch?v=g-41ZdcTnXc) lies upon it, and this is indeed very important device management and provisioning protocol, constructed to break the silos, so that you can connect and manage any IoT device, whatever on the MAC (6LoWPAN, LoRaWAN, ...) or PHY layer (802.15.4, 802.11, LoRa, ...). AllJoyn and Iotivity initiatives fall in the similar category, just that they are more P2P oriented, i.e. they put proximal networks in the focus and not client-server model.

Basically, LWM2M complient devices would go and register over CoAP to the server, then receive the commands or send (push) observable data.

For WiFi or 6LoWPAN it is evident, but for LoRa we can also imagine an architecture similar to this: https://github.com/telecombretagne/LoRaFABIAN - even HTTP2CoAP proxying is really easy thanks to the CoAP structure which was built in this way intentionally.

Quote:
It uses UDP so it should be able to run on DASH7.

I have read your posts about this, but I wanted to see with you do you know some real-world experiences of using CoAP over DASH7 (do we have some examples).

Quote:
The problem is that I looked at this last time in 2012, and all the work on CoAP was using silly function like malloc. Give me a break! This is embedded! Maybe now there is a static version of CoAP.

You should take a look at Erbium: http://people.inf.ethz.ch/mkovatsc/erbium.php, developed at ETH Zurich and used by the Contiki RTOS (http://www.contiki-os.org/) - which is probably the most professional IoT RTOS-es, widely used in the industry over many years. It is also used by the Wakaama LWM2M server by Eclipse foundation (https://github.com/eclipse/wakaama).

If you can give me some pointers, I would try to integrate this lib and make a PoC. As soon as I get some DASH7-capable HW :).

BR,
Drasko


Offline
 Profile  
 
PostPosted: Thu Sep 03, 2015 3:15 am 
Site Admin

Joined: Tue Jun 12, 2012 4:33 am
Posts: 25
Location: New York, NY
drasko wrote:
Quote:
[CoAP] looks like very sane, standardized (https://tools.ietf.org/html/rfc7252), well documented protocol with a lot of implementations in different languages. It looks to me like a best application layer protocol for IoT of all I have seen so far (I just started reading DASH7 spec, so I have no knowledge about this one yet).

...

I have read your posts about this, but I wanted to see with you do you know some real-world experiences of using CoAP over DASH7 (do we have some examples).

...

You should take a look at Erbium: http://people.inf.ethz.ch/mkovatsc/erbium.php

...

If you can give me some pointers, I would try to integrate this lib and make a PoC. As soon as I get some DASH7-capable HW :).


Last time I read the CoAP spec, I mostly liked it. I've met Zack Shelby, and he's a good engineer who is passionate about his project, so I love that about it, too.

The areas where CoAP can be improved for DASH7 are to bring any query functionality down one layer (like HTTP Gets), to integrate the CoAP data with the DASH7 FS (not too hard), to change the port data for ALP data (tricky), and to use DASH7's native, logarithmic retry model. However, at the beginning, I'm inclined to do a direct port of Erbium, and keep it simple. It will have similar performance as regular CoAP, which I would say is OK but not great. CoAP optimized for DASH7 will scream. It will probably allow 10x the network density as normal CoAP, because almost all response data will get piggybacked.

I'm going to audit Erbium over the next 5 days. I'll let you know what I think is the easiest path, and then what is the best long-term path.

On examples, I have built UDP apps for DASH7 using OpenTag's session framework. OT sessions are like DASH7 sessions, and it uses a tail-chained queue that prioritizes the dialog in progress over future dialogs/sessions. It's a little bit weird, but it is architected in order to pack-in a lot of functionality into a small code size. I think Haystack's entire gateway query API and app protocol fits into 4KB of ROM ... and it does quite a lot.

On hardware, I have a ref design for an arduino-shaped board. I think I'll open source it this month, and set up order queues from oshpark and tempo-automation. If you want to stuff it yourself, that's great.


Offline
 Profile  
 
PostPosted: Thu Sep 03, 2015 7:36 am 

Joined: Tue Sep 01, 2015 8:31 pm
Posts: 24
Location: Paris, France
Quote:
I've met Zack Shelby, and he's a good engineer who is passionate about his project, so I love that about it, too.

Yes, I tottaly agree. I had not have honor to meet Zach, but I have read a lot of his papers and watched every video I could find. I must addmit I am impressed by his approach and clarity, as well as engineering practice he demonstrates. This is of course a big plus for CoAP/CoRE, at least from the stand point of open source community.

Since ARM quisition of Sensinode they have been steering it in really good direction, standardizing and promoting CoAP and LWM2M approach, so it would be very interesting to see what mbedOS will bring: https://www.mbed.org/technology/os/, especialy mbed Device Server (https://www.mbed.org/technology/device-server/). While mbed is an ecosystem that should remove embedded development pain (but in profesional way, not Arduino-like), Device Server is here to facilitate device management, and this will be primarely done with LWM2M. From what I see so far mbedOS will come with pretty impressive IoT stack - TLS/DTLS, CoAP, MQTT, LWM2M, 6LoWPAN... Form my knowledge, of all the RTOS-es I have evaluated, only Contiki and Riot (http://www.riot-os.org/) come with this extensive IoT networking stack, while NuttX (http://nuttx.org/) is also a good candidate (needed libs can be easily added). Cool with this RTOS-es is that they already support a bunch of MCU platforms, and have a great deal of peripheral drivers.

Well, all this to say that with this approach we can expect further popularisation of CoAP and LWM2M, and it would be really good to have DASH7 (as well as LoRa) also covered, so that the choice of radio depends on the application, but one can keep the upper layers unchanged.

Quote:
The areas where CoAP can be improved for DASH7 are to bring any query functionality down one layer (like HTTP Gets), to integrate the CoAP data with the DASH7 FS (not too hard), to change the port data for ALP data (tricky), and to use DASH7's native, logarithmic retry model. However, at the beginning, I'm inclined to do a direct port of Erbium, and keep it simple. It will have similar performance as regular CoAP, which I would say is OK but not great. CoAP optimized for DASH7 will scream. It will probably allow 10x the network density as normal CoAP, because almost all response data will get piggybacked.


I must admit that at this point this is all Greek to me :). I just discovered DASH7 (although I heard about it a long time ago, but for some reason underestimated it. Marketing matters, I guess...), so I will need some time to get into the standard.

At this point, I see it like this: since DASH7 can do UDP, then it can do CoAP over it. It will probably be unoptimized, but it is a first step and good PoC. Then second step would be optimizations, but I would go through an official process of proposing IETF draft. These are good pointers:
- https://tools.ietf.org/html/draft-pelov-core-cosol-00
- https://tools.ietf.org/html/draft-silve ... nsports-02
In the last one you can see DASH7 already mentioned, but it is maybe too generic, and probably some more specific draft would be needed - like the one for CoAP over LoRaWAN.

Quote:
On examples, I have built UDP apps for DASH7 using OpenTag's session framework. OT sessions are like DASH7 sessions, and it uses a tail-chained queue that prioritizes the dialog in progress over future dialogs/sessions. It's a little bit weird, but it is architected in order to pack-in a lot of functionality into a small code size. I think Haystack's entire gateway query API and app protocol fits into 4KB of ROM ... and it does quite a lot.

I have been just looking through OpenTag code so far, did not use it. It is really impressive peice of work!
I guess DASH7 stack really need some scheduling, as I can see you have implemented full RTOS. OSS-7 apprach also implements OS (https://github.com/MOSAIC-LoPoW/dash7-a ... urce-stack). So I guess without some kind of scheduling you can not have DASH7 functionality.

A question at this point is how difficult would it be to have OpenTag DASH7 stack as a separate lib. I guess that for OSS-7 this should not be so hard, as all their stack is here: https://github.com/MOSAIC-LoPoW/dash7-a ... dules/d7ap, and can be compiled as a static lib.

I am asking this because I think it would be a really good idea to run this stack on a Linux PC, to which you would connect RF chip via USB dongle, or some other bus (SPI, I2C, UART, ...) if you would like to use an addon board (shield) for aome Linux carrier board. This would open up the usage for not only PC, but also tons of Linux boards out there, as RPi, Beagle Bone Black, CHIP, ...

Having OpenTag running natively on Linux PC would also help debugging and app development a lot, I guess.

Quote:
On hardware, I have a ref design for an arduino-shaped board. I think I'll open source it this month, and set up order queues from oshpark and tempo-automation. If you want to stuff it yourself, that's great.

I really liked the fact that you have chosen SPIRIT1 for the HW. I have been looking at this chip since the announcement, and I am glad that you had good experiences with it. I also consider STM32L1xx as a smart choice.

This looks to me as a perfect unexpensive dev board for DASH7: http://www.st.com/web/en/catalog/tools/PF258710.

If we could have a native Linux support, then I guess something like this could be even more adequate: http://www.st.com/web/en/catalog/tools/PF261272, as you would need only transceiver, not the actual CPU (I do not know if on the previous dongle we can disactivate MCU and hit directly SPIRIT1 from the USB, probably with AT commands).

I am not really a fan of Arduino, so I find this approach more appealing.

BR,
Drasko


Offline
 Profile  
 
PostPosted: Sat Sep 05, 2015 2:59 am 
Site Admin

Joined: Tue Jun 12, 2012 4:33 am
Posts: 25
Location: New York, NY
There's actually a "secret project" I'm doing to integrate OpenTag as a tickless kernel BIOS for NuttX. The DASH7 networking will also come for free, along with all the other features in OT, like transparent energy optimization. As far as I know, there's no other embedded RTOS that optimizes CPU clock and sleep modes the way OpenTag does. Contiki and RIoT are nice in many ways, but in my opinion they have a major drawback: they were designed as operating systems first, and low-power networking second.

I like NuttX. The implementation is tightly coded and written in a way that makes "real programmers" proud -- just like OpenTag.
http://www.ee.ryerson.ca/~elf/hack/realmen.html

...

I am interested in adding support for three new radios: AX5243, LoRa, and CC13xx. After these (and currently supported SPIRIT1), I find no other sub 1GHz transceivers on today's market compelling at all.

...

I would like to build a version of OpenTag that uses Pthreads for simulating all the hardware, so that it can be simulated easily on Mac or Linux PC. I would rather find someone looking to do a masters thesis, though, than do it myself. ;) Anyway, I think this would take me two weeks of work to do. But, it is one of those things that isn't quite a priority.

...

OpenTag DK boards are shaped like Arduino, but they use STM32L1. This is an old MCU, but a good one. STM32L0 and L4 are really interesting. I think ST is going to revamp the L1 quite soon, which a die-shrink to 90nm and new features. L4 is the perfect target for a NuttX+OpenTag device which includes sophisticated public key encryption & authentication. Of course, I don't think the IoT market is ready for that kind of innovation until 2020.


Offline
 Profile  
 
PostPosted: Sat Sep 05, 2015 7:55 pm 

Joined: Tue Sep 01, 2015 8:31 pm
Posts: 24
Location: Paris, France
Hello JP,
I can see we are on the same wave length over many of these questions.

Quote:
There's actually a "secret project" I'm doing to integrate OpenTag as a tickless kernel BIOS for NuttX. The DASH7 networking will also come for free, along with all the other features in OT, like transparent energy optimization. As far as I know, there's no other embedded RTOS that optimizes CPU clock and sleep modes the way OpenTag does. Contiki and RIoT are nice in many ways, but in my opinion they have a major drawback: they were designed as operating systems first, and low-power networking second.


Wow, great! I think NuttX is great choice for this. I do not know well Contiki nor RIOT power saving features. I guess that their real benefits are networking stacks (while you have to add this to NuttX manually).

Quote:
I like NuttX. The implementation is tightly coded and written in a way that makes "real programmers" proud -- just like OpenTag.


I agree with this 100%. Greg has done some magnificent work there, NuttX is also my first RTOS of choice.

Quote:
I am interested in adding support for three new radios: AX5243, LoRa, and CC13xx. After these (and currently supported SPIRIT1), I find no other sub 1GHz transceivers on today's market compelling at all.

AFAIK CC13xx is still unavailable. BTW. here is one very interesting debate on TI vs LoRa RF chips: https://e2e.ti.com/support/wireless_con ... 73/1477077

Quote:
I would like to build a version of OpenTag that uses Pthreads for simulating all the hardware, so that it can be simulated easily on Mac or Linux PC. I would rather find someone looking to do a masters thesis, though, than do it myself. ;) Anyway, I think this would take me two weeks of work to do. But, it is one of those things that isn't quite a priority.


I was thinking exactly about this - pthreads implementation for Linux "native" verison - so that we can develop apps quickly.

Quote:
OpenTag DK boards are shaped like Arduino, but they use STM32L1. This is an old MCU, but a good one. STM32L0 and L4 are really interesting. I think ST is going to revamp the L1 quite soon, which a die-shrink to 90nm and new features. L4 is the perfect target for a NuttX+OpenTag device which includes sophisticated public key encryption & authentication. Of course, I don't think the IoT market is ready for that kind of innovation until 2020.

ST Microelectronics has great line of chips, and they usually play well open source - this is what I like with them. I have one of their headquarters near my house in Paris, and I have been in very good contacts with them - they were always helpful and they are very interested in boosting up innovative uses of their chip line. I guess that they would be very interested in hearing about projects like this!

In any case - I think that STM is a great choice for this project.

But I was wondering - what would you think about a simple USB dongle with RF transceiver only (i.e. only Siprit1, not STM32L1) ? If we could have a "native" pthread version, then we can program this RF chip via USB. This dongle can later be reused on RPi, Beagle Bone Black, CHIP board, whatever. And this could be a quick way to get acquainted with DASH7 technology, before you go deeper in embedded subjects (power saving, ...).

BR,
Drasko


Offline
 Profile  
 
PostPosted: Sun Sep 06, 2015 4:22 am 
Site Admin

Joined: Tue Jun 12, 2012 4:33 am
Posts: 25
Location: New York, NY
I have some CC13xx kits, although they are kind of useless until TI releases firmware libraries for it. CC13xx can support DSSS and k=7 convolutional coding, which is very powerful. When combined with the Haystack Adaptive Reed Solomon Codec, this solution beats LoRa by 4dB, and it does it without any secretive, proprietary, technology.

...

To make a USB stick, it still needs an MCU. OpenTag on STM32L has a 8us latency, which is comparable to the best Real Time Linux kernels. However, almost no one builds these for their PCs, so it is silly to discuss. Another problem problem is USB, so even if you have an RT Linux kernel, you still need to deal with the ~10ms USB latency.

What is more practical for me is to simulate the entire PHY in software, and run multiple simulated devices on a single POSIX system. This should be fine for the purpose of app development and load testing.


Offline
 Profile  
 
PostPosted: Sun Sep 06, 2015 11:25 am 

Joined: Tue Sep 01, 2015 8:31 pm
Posts: 24
Location: Paris, France
Quote:
I have some CC13xx kits, although they are kind of useless until TI releases firmware libraries for it. CC13xx can support DSSS and k=7 convolutional coding, which is very powerful. When combined with the Haystack Adaptive Reed Solomon Codec, this solution beats LoRa by 4dB, and it does it without any secretive, proprietary, technology.


Two questions:
1) How open are these Haystack algos - i.e. can they be used in a commercial products? Or these are some patents that have to be licensed from Haystack?

2) Does this mean that with CC13xx DASH7 can have a longer range than LoRa? I saw that you mentioned over 3km with Spirit1. What do you expect with CC13xx?

Quote:
To make a USB stick, it still needs an MCU. OpenTag on STM32L has a 8us latency, which is comparable to the best Real Time Linux kernels. However, almost no one builds these for their PCs, so it is silly to discuss. Another problem problem is USB, so even if you have an RT Linux kernel, you still need to deal with the ~10ms USB latency.


Ah, I was not aware that such a small latencies are mandatory to drive the RF transceiver. In that case, I agree that making the dongle with RF transceiver only does not make sense.

Are OpenTag DK boards boards available and where they can be ordered?

Best regards,
Drasko


Offline
 Profile  
 
PostPosted: Sun Sep 06, 2015 10:08 pm 
Site Admin

Joined: Tue Jun 12, 2012 4:33 am
Posts: 25
Location: New York, NY
drasko wrote:
Quote:
1) How open are these Haystack algos - i.e. can they be used in a commercial products? Or these are some patents that have to be licensed from Haystack?

2) Does this mean that with CC13xx DASH7 can have a longer range than LoRa? I saw that you mentioned over 3km with Spirit1. What do you expect with CC13xx?


The Reed Solomon Codec is proprietary. It may be licensed as object code for reasonable terms. Right now, it is too valuable to open source.

We can get 3km in clear, outdoor conditions, using 4mW TX and ~7kbps narrowband. The CC13xx has an 8-10dB advantage over the SPIRIT1, though, in real-world conditions. I can't say exactly what the performance will be yet, but for data rates between 5-50kbps, it should have notably superior performance over LoRa. For data rates below 1kbps, LoRa should still have better performance.

...

The problem with DK boards is that they are expensive to build and support. I want to find some way to just give away the DK board design, so that companies in the business of building these things will do the production and fulfillment. Maybe you have some ideas. I've found an STM32L+LoRa kit from Modtronics, which may also be easier to port-to.


Offline
 Profile  
 
Display posts from previous:  Sort by  
Post Reply  Page 1 of 2 [ 12 posts ]  Go to page 1, 2  Next

It is currently Sun Dec 17, 2017 3:55 pm


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  

cron