RF modules (LoRa et al)

[espruino-discuss2]

Posted at 2014-12-10 by DrAzzy

So there's a lot of interest here in LoRa/radio that works at reasonable ranges and doesn't generally suck.

It looks like there are two product lines that are worth investigating for LoRa - RFM9x... series, and the Semtek SX1272,1276,1278.

The RFM92 and RFM95 seem to be the interesting ones for LoRa. These are often advertised as being compatible with SX1272 and 1276 respectively. The 1276 and 1278 are very similar.

Has anyone tried any of these?

Has anyone written modules for any of these?

At least one of us is going to need to take the plunge and write a module for one of these (that might be me), but it'd be best to make sure the module was written for the part that the greatest number of people would be able to reuse.

Also:

Has anyone tried the RFM69W? It's fairly cheap, and works on 433 mhz - I'd love to know how well, or poorly, it works. It looks like it's got significantly higher transmit power than the cheapo ones, as well as the builtin decoder/encoder.

Anyone know of any other LoRa transceivers that might be a better choice?

[espruino-discuss2]

Posted at 2014-12-12 by Manxome

I have some RFM69HW's (long range version of RFM69W) coming in next year but this is all virgin territory for me, so it'll be slow going.

[gfwilliams]

Posted at 2014-12-12 by @gfwilliams

The last thing I read on 'LoRa' implied that it needed some kind of base station in order to work... Or am I getting confused?

On a slight tangent, I just took an eQ-3 MAX! wireless radiator valve to bits and discovered it's got a CC1101 chip in it, transmitting at 868Mhz. Looking on eBay there are a whole bunch of modules available with that on too - boasting around 350m range.

Seems it's got a whole load of interesting packet handling stuff on it, including the ability to automatically turn the receiver on every Y ms, and then only wake the MCU up if it gets something. It'd be great for low power stuff.

[espruino-discuss2]

Posted at 2014-12-12 by DrAzzy

LoRa doesn't need base station as far as I can tell... I haven't seen any indication in the descriptions on hope rf's page, nor on tutorials like this one http://www.cooking-hacks.com/documentation/tutorials/extreme-range-lora-sx1272-module-shield-arduino-raspberry-pi-intel-galileo

Oh interesting - so the CC1101 might be another choice, though it sounds like it's a bit cheaper and shorter range than LoRa devices. It looks like it's similar to the RFM69xx.

[espruino-discuss2]

Posted at 2014-12-12 by Manxome

Regarding base stations...you have a number of these LoRa nodes out there, all acting asynchronously, something needs to be 'ON' and listening all the time that they can talk to, right?

This guy (below) uses a base station which is basically another LoRa node but plugs through usb to a computer running an app that gathers transmissions, logs, takes stats, connects to internet, etc. He says you don't really so much program the nodes, you configure them in the app, and it is the app where you add your code. I am guessing that the nodes 'wake' up and transmit their pin status to the app which tells them what to do next, but that is just my guess until I get my hands on a few. Thinking about it though, it is an interesting way to go. The nodes all have one simple program, not requiring much cpu or memory or battery power or need to re-program out in the field etc. The KS project failed, but he is making them available online anyhow.

Hmmm, I tried to make a 'link', but nothing was happening, so:
https://www.kickstarter.com/projects/1630453569/whisker-iot-invention-system

[espruino-discuss2]

Posted at 2014-12-12 by DrAzzy

Hmm, My understanding, which may be wrong, is that it would be up to the user (well, whatever you and I would be called) to decide if they wanted to have one node running continually, and call it a base station. I didn't see anything that implied that there had to be a single "special" node. In the case of the Whisker, they do have a base station, but I think that's specific to Whisker, not LoRa in general.

[espruino-discuss2]

Posted at 2014-12-12 by Spocki

It really depends on what you want to do: point-to-point, base station, relay, broadcast, mesh etc. and the protocol to decide on. I'm still learning event driven Javascript, so I'm not the ideal person to do this, but if one of you guys (Gordon?) want to do it, have a look at this (Arduino, so +/- C) library: http://www.airspayce.com/mikem/arduino/RadioHead/. Great work, just translate ;-)

[espruino-discuss2]

Posted at 2014-12-16 by d0773d

@drazzy I checked out the link that you posted and wow those modules seem expensive especially €140.00(174.16 USD) for the Waspmote Gateway kit. I am assuming the range justifies the price?

[espruino-discuss2]

Posted at 2014-12-16 by DrAzzy

What link is this???

All the stuff I was looking at was much cheaper, and I didn't read anything about a gateway in this context. So I have no idea what toe taking about.

[espruino-discuss2]

Posted at 2014-12-16 by d0773d

@drazzy In post #4 you wrote this link: cooking-hacks.com/documentati­on/tutorials/extreme-range-lora-sx1272-m­odule-shield-arduino-raspberry-pi-intel-­galileo

I scrolled through the page where it lists links under Kits and started clicking through the links to browse the different LoRa products they designed/carried and noticed the prices. Also: http://www.cooking-hacks.com/shop/arduino/designed-by-ch/extreme-range-lora-sx1272-module-shield-arduino-raspberry-pi-intel-galileo

Sorry for the confusion.

[espruino-discuss2]

Posted at 2015-03-21 by Jasonwu

The lora module is really amazing performance. I have tested the LoRa module based on SX1276. The working range is up to 10km through several woods. Though the manufacture of the module claim the range is only 5km. The below link is the detail of LoRa.
http://www.appconwireless.com/PRODUCTS/showproduct.php?lang=en&id=21

[espruino-discuss2]

Posted at 2015-03-21 by DrAzzy

@Jasonwu - were you using it with the Espruino? If so, do you have any code? We'd love to see it, if so!

I think right now there are like 5+ of the most active members of the forum with at least one kind of LoRa or RF module sitting around, but none of us have bothered to write so much as 1 byte of code!

[espruino-discuss2]

Posted at 2015-03-28 by @joakim

Microchip is coming out with a new LoRa module in May that will sell for $10.90 in 1,000+ unit quantities. Maybe not so maker friendly, and it will definitely be more expensive for us mere mortals…

DASH7 is another interesting alternative. It's a particularly good fit for telemetry with its event based BLAST (Bursty, Light, Async, Stealth, Transitional) design, low power use and good range outdoors and indoors. It's a pretty nifty protocol! I especially like the query functionality.

It's also got an open source implementation, OSS-7, which as it happens has already been implemented for STM32L. Which means it's not too hard to port it to Espruino, right? I don't know the compiled size of OSS-7, but the protocol stack of DASH7 is said to be small.

There's also OpenTag, but it looks stale and is not supported by DASH7 Alliance (OSS-7 is).

[espruino-discuss2]

Posted at 2015-03-28 by @joakim

Curiously, the guy behind OpenTag wrote this blog post just yesterday:
LoRa as a PHY for DASH7

[espruino-discuss2]

Posted at 2015-03-30 by alexanderbrevig

I'm currently working with DASH7 and not incidentally I have access to both STM32 and CC430 on my board. I'll report sizes etc when I get the parts and everything set up. Of cource, if I ever end up porting it to an Espruino library (I think it will happen, but probably not until after first protos are up and running using the cc430) I will post it for everyone to use :)

If my design is flawed I also have access to a few WizziMotes from WizzeMote so sooner or later I'll post some info on Espruino and Dash7 :)

[espruino-discuss2]

Posted at 2015-03-30 by @joakim

@AlexanderBrevig Hah, awesome! We definitely need to grab a beer and talk Espruino soon (and DASH7). As a quick teaser, I'm planning to use DASH7 with Espruino for small low-powered sensors that push data online via a gateway. Not so different from what you're doing. I'm currently abroad but will be back in Norway after easter, I'll send you a message then.

Btw, OSS-7 also supports M4 (Pico), I just noticed.

[espruino-discuss2]

Posted at 2015-03-31 by @joakim

€15.66 is much cheaper than the WizziMote's €40 though. It lacks an antenna connector, but has an accelerometer and a thermistor.

To continue my train of thought on Cortex-M4 MCUs with sub-1GHz RF, this one comes close:
http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=KW0x#MKW01Z128CHN

Costs from €5.39 to €3.21 at Farnell (£4.30-2.57), about the same as CC430F5137.

It's got a Cortex-M0+ with 48 MHz, 128 KB flash and 16 KB RAM, which Espruino should be able to run on. But how handicapped would Espruino be? How much would have to be stripped away? I know one doesn't need all of Espruino's features on a simple IoT sensor device, but would it be able to remain a good platform to run simple IoT sensors? Or would it be too limited for even that?

Am I right in thinking it's mainly a question of time and effort that is needed to make Espruino run on the chip, including porting it to the MCU and stripping it down?

[gfwilliams]

Posted at 2015-03-31 by @gfwilliams

Wow, that's a really interesting chip.

There's already a version of Espruino that runs on 128kB flash, 8kB RAM. It's tight, but it does fit in with a few features removed. As flash is really the limiting factor, and on normal Espruinos some of it is used to store saved JavaScript, you could just stick a cheap SPI EEPROM/FRAM chip on the side of it.

I think you could get something pretty usable out of it - people have been feeling a bit limited by the amount of code you can get into 48kB (so 16 would be pushing it) but I think for simple sensors and stuff it's entirely adequate.

Espruino was also designed from the start to run from external memory - while I've never had a need to do it because 256kB uCs got cheap, it would be possible (without massive amounts of effort) to implement it. At the expense of some execution speed, you could have it running with loads of available memory.

Anyway, obviously I'm a bit busy at the moment, but once the Picos are out the door and the inevitable firefighting is done, I'd be really interested in coming up with something based on that.

Having said all that, the easy (and probably cheaper) solution would be to take a 256kB STM32F030 (which are $1.13 at 10k off) and slap a cheap transceiver on the side (MRF89?). Virtually no software effort required at all then.

[espruino-discuss2]

Posted at 2015-03-31 by @joakim

Yup, the MKW01Z128CHN­ (most difficult name I've ever seen) got more and more interesting as I read the datasheet, looks like a nice design to my untrained eye.

You're absolutely right that there are cheaper and easier ways to do low-powered RF, I was really trying to find the ideal solution for a tiny low-powered wireless sensor. That's a long way off, but I like checking out the territory in advance.

STM32F030 with 256 KB doesn't seem to be out yet, at least not in lower volumes, but it looks like a good option in combination with an external transceiver. Very good point about no extra software effort required!

I've been thinking about the possibility of using external memory. Good to know it's not too difficult, should the need for that arise some day.

Good luck with the firefighting and shipping! I'm very grateful that you're making Espruino at all, it has opened up the world of microcontrollers for me :)

[espruino-discuss2]

Posted at 2015-03-31 by alexanderbrevig

During my experimentation I've found that it's really hard (at least for me) to find a way to run a 'dumb' RF transceiver reliably. It seems to shine first when you have a good BLAST implementation on top (at least for 433, the band MRF89 operates in is somewhat more reliable).

After trying various devices and bands with different protocols I ended up betting on Dash7.

Keep in mind I'm no RF wizard, and the tests are mostly on the form of "how long can I walk in this direction before packet loss".

---

Furthermore, in terms of code size and memory; I've made a proof of concept where I have the actual Dash7 interface written as part of the Espruino itself as a library (I'm cheating right now though, it just talks with the cc430 using serial). Then the user can bind Dash7.onMessage(function, {options...}) functions, and use Dash7.send(message, {options...}); to send messages.
This way, you don't really need much RAM to store the user program. It also makes sense to remove some of the other libraries for an IoT tailored device. The leaf nodes does not need a www stack for instance.

For me, I want my programs to end up looking something like my proof of concept:

var dht = require("DHT11").connect(C11);

//loss of connection rules
Dash7.connectionLost(function(fails){ 
    clearInterval(); 
    Dash7.disconnect(); //currently I have it on a fet so I save battery this way
    if (fails > 10){
        analogWrite(B2, 0.5, {freq: 1000});
        setTimeout(function(){ analogWrite(B2, 0); }, 1000);
        Dash7.clearErrorFlags(); //reset fails counter
    }
});

//conneced behaviour
Dash7.connect(function(meta){
    console.log(meta);
    Dash7.messagePrefix = "/telemetry/" + meta.address; //this is sytem side soft address, not mac

    //broadcasted messages
    Dash7.onMessage(function(msg){
        if (msg.data === "alarm") {
            analogWrite(B2, 0.5, {freq: 1000});
        } else if (msg.data === "alarmOff") {
            analogWrite(B2, 0);
        }
    }, { routedTo: "all" });

    //messages to me only
    Dash7.onMessage(function(msg){
        if (msg.req) {
            Dash7.sendAck(); 
        } 
    }, { routedTo: "me" });

    //sensor aggregation loop
    setInterval(function(){
        dht.read(function (a) {
            Dash7.send("/temperature/" + a.temp.toString(), { to: "gateway" });
            Dash7.send("/humidity/" + a.rh.toString(), { to: "gateway" });
            //planned using mesh or mesh-cloud-mesh routing
            //Dash7.sendMessage("/humidity/" + a.rh.toString(), { to: 0xbadf00d });
        });
    }, 10000);
}, 5000 /*retry interval, will also still retry if disconnect during operation*/);

I'm rambling now. I'll stop.

[espruino-discuss2]

Posted at 2015-03-31 by @joakim

No need to stop, this is great stuff! :)

Your POC code looks very promising, I'd definitely be interested in contributing in whatever way I can. Looking forward to talking more about this over a beer some time after easter!

[gfwilliams]

Posted at 2015-03-31 by @gfwilliams

Yes, that kind of interface looks good - it might even allow something like the MQTT module work on top of it if people wanted.

For decent battery life you'd definitely want at least the decoder to sit inside the radio itself, but there is the option of sticking all the radio implementation on a second micro. I've seen a few devices based on the CC1101 (SRF and eRIC) - but that seems like it might still end up being quite expensive.

[espruino-discuss2]

Posted at 2015-03-31 by @joakim

Assuming DASH7 is used, wouldn't OSS-7 on a CC430 be just that?

@AlexanderBrevig Btw, are you using OSS-7 on the CC430?

[espruino-discuss2]

Posted at 2015-03-31 by alexanderbrevig

@joakim Glad you found my POC interesting :) Yes, the CC430 is using a modified version of star-push-endpoint and I also peeked somewhat to the sample code that you get access to when buying the WizziLab stuff.

The reason my development board has both the STM and the CC430 was so I could be guaranteed to show off both the JavaScript aspect of the product (through Espruino of course) and Dash7 (through OSS-7). I am still hoping to find a cheaper solution before making something intended for a paid user test, rather than a free one.

OSS-7 is not exactly self documenting, though I'm beginning to get a grasp around their ideas now.

@gordon I can't believe I've not thought about the fact that using Dash7 on the STM would basically prevent it from going into sleep mode. Probably stuck with the need of having two processors then. As battery life is of importance I'll have to scratch my head a bit.

[gfwilliams]

Posted at 2015-04-01 by @gfwilliams

As far as STM32 and sleep, you can still do pretty well - nothing stops you from waking from sleep on an interrupt, doing stuff, and then going back to sleep without Espruino running - which should still be pretty efficient especially if you can do what you want without powering up the external high speed oscillator.

Still, even having some basic decode in the receiver and a tiny FIFO (so no packet handling or anything) would bring the power consumption down drastically.

[espruino-discuss2]

Posted at 2015-04-08 by d0773d

@AlexanderBrevig This might be too soon for me to ask... I was wondering how far you have gotten with the WizziMotes? I purchased a couple of panStamps, one for the Gateway and one to connect to the Espruino. The panStamps can be used as standalone, but I plan to communicate back and forth between the espruino and the panStamp either I2C or uart. I've gotten no where on utilizing AES encryption and gave up on the idea and resorted to your idea of off loading encryption to another chip. Since the panStamp does:

CTR is implemented in the CC430AES class, which is the cipher method
used by SWAP. CTR, unlike some other methods, allows encrypting and
decrypting variable-length packets. First four bytes from the packet
(destination, source, hop/secu and nonce) are used as the initial
nonce for the CTR algorithm.

I plan to program the panStamp to send any incoming packages to the espruino and vise verse. I shall see how that idea works. I don't have any of the boards yet and hope to receive them either this week or the next.

[espruino-discuss2]

Posted at 2015-06-16 by LawrenceGrif

I did some very crude range testing with the Appcon and got 800+ meters in urban environment on a rainy day with lots of trees & antenna at <1 meter. I would recommend the module for your own use but it's not CE marked or certified on the RF side. http://www.appconwireless.com/PRODUCTS/showproduct.php?lang=en&id=21

[espruino-discuss2]

Posted at 2016-01-08 by Jasonwu

Appcon wireless LoRa module RF1276 perform a good range test in the coast area. It get the 10km in Italy.
http://iot.dataino.it/beta/view/site/lora-arduino-gps.html

[espruino-discuss2]

Posted at 2016-01-08 by Jasonwu

the link was changed.
http://www.appconwireless.com/ProShow.asp?id=337

[gfwilliams]

Posted at 2016-02-05 by @gfwilliams

Just a quick update: There are now drivers for the SX1276 on Espruino.

They're still a bit rough, but it's enough to get the modules up and running and transferring data - so should be a good starting point for anyone looking at using LoRa (not LoRaWAN) with Espruino.

[espruino-discuss2]

Posted at 2016-04-11 by MediMALES

Hi everybody,
I work with the SX1272mb2das Module for implemented the LoRa protocol, I and i use a SEMTECH gateway with a server LoRa( IOT868STK ) but i can't configurated the gateway. there's someone there who work on a similar topic !! the links of the program :
https://developer.mbed.org/users/swquin/code/LoRaWAN-demo-72-bootcamp/file/d28441b09772/app

Thx for ur help :)