LowPowerLab Forum

Hardware support => RF - Range - Antennas - RFM69 library => Topic started by: GeorgeR on January 02, 2015, 01:36:22 AM

Title: LoRa RFM95 RFM98
Post by: GeorgeR on January 02, 2015, 01:36:22 AM
Hi Felix,

Some nice work here, well done, I also see that the footprint of the 69W is exactly the same as the RFM95-98 LoRa boards, have you done any testing on the LoRa boards, if so how does your library stack up? The distances on the LoRa with a Data Concentrator from SemTech (SX1301) are reaching distances of 15-22 Km's Line of sight.

Regards
Title: Re: LoRa
Post by: Felix on January 02, 2015, 08:40:27 AM
Hi George,
I have not really looked into LoRa yet. Probably something worth looking into. Just don't have the time to spread so much these days.  A lot to catch up with.
Thanks for the pointer. If you have more info please feel free to share here.
Title: Re: LoRa RFM95 RFM98
Post by: GeorgeR on January 02, 2015, 09:09:24 AM
Hi Felix,

Thanks for the reply, I have been doing some digging since posting and have discovered that Mike McCauley of Airspayce.com has tested their Radiohead library on your boards (I speak under correction here, it seems including RFM95, 22B & 69W).

It seems one could substitute the radios (69 for 95) and then use his radiohead library 'et Voila... I anticipate a couple of changes to the library may be required.

What I have found is there is no AES encryption on the LoRa chips but does have CRC, not a secure solution then! But DAMN!!! what a range.

I will update if I find anymore info.

Regards
Title: Re: LoRa RFM95 RFM98
Post by: Felix on January 02, 2015, 11:01:37 AM
Some consider AES not strong enough, and you can implement AES or another stronger algorithm in firmware but that takes serious cycles from the little atmega chips. So it's a tradeoff.
It's cool that the pinout is the same though. CRC is pretty important and having it in hardware also saves some cycles and avoids unnecessary interrupts.
Title: Re: LoRa RFM95 RFM98
Post by: GeorgeR on January 03, 2015, 02:56:41 AM
OK, some clarity on the foot prints, the RFM95 has the same footprint as the 12B (16x16) which is the same footprint as the RFM69HCW (16x16),
whereas the RFM69W and 69HW both have a footprint of 16x19, thus with a bit or programming, the 12B boards are good for LoRa RFM95 rf units with the RadioHead library.

I had pulled the 69HCW datasheet in error thus got the footprints wrong, my bad! However, the opportunities due to this work is endless, I like the idea of the RadioHead mesh (Auto route discovery for a series of Base Stations) and the MoteinoMEGA (The mesh memory usage for the 328 will be too much I have read), just need a GPS to compliment the combination, I will try this out in protype and revert when I am done.

Title: Re: LoRa RFM95 RFM98
Post by: Felix on January 03, 2015, 05:05:44 PM
Meshing and autorouting is a hard problem to get right. That's why I prefer range over meshing, if at all possible, it eliminates a whole layer of issues you need to worry about.
Title: Re: LoRa RFM95 RFM98
Post by: GeorgeR on January 04, 2015, 03:41:03 AM
Hi Felix

Taking a step back here, and am seeking advice from the better informed, lets assume I have a range of 20-30Km's I need to cover, comprising of hilly and flat terrain, I can only use ISM frequencies (433/868/915), and wish to track a number of movable assets within this range, the asset count may exceed 300 and all need to be on the same network, (i.e.) when in range of a basestation it will communicate with that basestation with the strongest RSSI and be recognised at any basestation in the network. The node communication will be occasional only (i.e. 1 comms per node per hour, yep will need an RTC).

What network type and radio setup based on what I have mentioned above can one use to track the devices, I have seen that the device(radio) ID is a byte, that leaves me 255 possible nodes in a single network, is this defined by the radio(rfm69) or the software as I have not found the answer in the radio docs yet.

Unless of course the node ID's can all be the same bar the base stations and have the first 2 bytes of the data hold a custom ID, but this means we cant reprogram over the air via a push which may be neccessary from time to time.

That I think is about the only thoughts and questions I have at this stage, any advice in this regard will be highly appreciated.

Many thanks

Edit:
I have found the ID is a byte on the radio, thus with this restriction one might consider all the permanent ID's to be that of the base stations(BS) only, then when a node broadcasts, it will handshake with all audible base stations, the BS with the strongest RSSI becomes the controlling BS and issues a temp ID to the requesting node. If the BS has issued all ID, perhaps send a wait to other requesting nodes, the node can then fall over to the next strongest rssi BS or wait as requested. The node can release the ID and/or the ID can expire at the BS after n-millis ...  just thinking...!