RF modules (LoRa et al)

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?

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.

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.

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.

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

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.

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 ;-)

@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?

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.

@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.

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

@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!

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).

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

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 :)

@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.

@alexanderbrevig if you have time, can you post a review on the WizziMote(s)?

I did a quick google search for: CC430F5137
and stumbled across: http://www.panstamp.com/ which seems interesting. I think it can do mesh networking and has AES128 encryption.

It does look interesting, the price isn't too bad either, and it's open source. Too bad CC430 doesn't run Espruino (yet?)…

Hm, what ARM Cortex-M4 based MCUs are out there that have a built-in sub-1GHz RF transceiver? Something like the nRF51822, only for sub-1GHz. That would make Espruino based low-power IoT devices/modules easier to build, and cheaper to produce.

@d0773d There's not really much to say. It's basically just an expensive cc430 on a breakout board.

PROS:

• Documented 'getting started' guide for building the Dash7 stack
  
• Comes pre programmed with a working and useful sample program
  
  

CONS:

• Price
  
• Documentation is really not that 'easy' (i.e this is not a dev board for everybody, you should have experience building toolchains and debugging odd errors. [google is your friend]). I know this also was one of the PROS, I do think it's easier to pick up a wizzi than to try to build for some other dev board using the dash7 api. You need to pay to get access to the wiki with documentation.
  

€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?

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.

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 :)

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.

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!

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.