Summary of Transceivers

Round 1

Reyax RYLR896 module (have 3 of them) – contains RYLR890 RF module (which apparently contains Semtech SX1276 RF chip) + STMicro STM32L151C8T6A MCU – has TTL async interface, so used USB to TTL serial to talk to it.  Reliable communications but weird, uses “AT” command set.  I see this as being a replacement for the EOL’d Linx Technologies FHSS radios on the RMM – but the command protocol is different, so I’d have to rework the Microchip PIC18LF4321 MCU code.  To replace the CM, I’d use this module and say the Silicon Labs EFM8UB2 Universal Bee to translate the weird commands to emulate the old Linx FHSS radio.  The EFM8UB2 has built-in USB interface, SPI, 8051 core, and lots more – I used it in the DC Module at ERLPhase, and I like the chip.  I have the dev kit for it.

Ronoth LoStick (have 2 of them) – contains Microchip RN2903 RF chip + USB interface.  I got them to talk to themselves, that was easy.  I’d love to use this to replace the Collector module, but it’s not clear how to get it to talk to the Reyax RYLR896, haven’t been able to make it work.  Its settings are very different than the Reyax RYLR896, so I haven’t been able to make them intercommunicate.  The internal design and internal software do not appear to be open source.

Waveshare SX1262 LoRa HAT for Raspberry Pi (have 1 of them) – contains EByte E22-900T22S RF module (which apparently contains Semtech SX1262 RF chip + not sure which MCU) also has USB interface that I used to talk to my computer directly to the EByte module.  This looks cool, has its own Wiki page describing it, and example code.  I modified a Python program to talk to it, but couldn’t get it to respond.  Tried all the baud rates, put a bunch of debug in there, just not responding… although I seem to see blinky lights saying that the RX & TX are working…

HopeRF RFM95W little LoRa module (have 2) – pretty small – almost small enough to use on a puck – castellated “postage stamp” SMT mount.  Apparently has an Semtech SX1276 RF chip inside – which should make it compatible with the Reyax RYLR896… it needs sync serial (SPI) and I have no easy way to talk to it.

Microchip (formerly Atmel) SAMR34 (have 1 DM320111 SAM034R Xplained PRO dev kit).  This is yet another architecture, contains a 32-bit ARM Cortex M0+ MCU and LoRa Transceiver.  I have not tried it yet.

Round 2

Seeed Systems Dragino LoRa/GPS HAT for Raspberry Pi has a HopeRF RFM95 (ordered 2 on 2020-04-11 – arrives in about 2 wks) (not “W” – not for North America) on it, but I plan to change it to my HopeRF RFM95W so can control directly from my Raspberry Pi through its SPI port.  This appears to be an open design with its own Wiki page, and there’s instructions on how to set it up to do LoRa on the Raspberry Pi, and Github code to do LoRa on the Raspberry Pi.  This LoRa/GPS HAT for Raspberry Pi also appears to be available from Antratrek in the UK.

Adafruit has a RFM95W LoRa Transceiver breakout board that would make it easy to play with the Hope RFM95W, but they are out of stock, Antratrek in the UK appears to have some.  There are similar products from Tindie and another one from Tindie.  Maybe I’ve got enough RFM95W options at present.

Ronoth  LoDev  ( Ronoth are the folks who made the LoStik).  It’s a bit newer than LoStik, appears to be a different focus.  It uses the AcSip S76S system-on-a-chip (which they call SiP – System in Package).   The S76S contains a Semtech SX1276 RF chip and a STMicro STM32L073x MCU.  It’s sold out at Ronoth, but CrowdSupply says they have some, so I ordered 2 pcs from CrowdSupply on 2020-04-12.

Round 3

I retrieved my personal Raspberry Pi 3 B+ from the office – where I had it placed to facilitate my staff being able to navigate to an important source scanning site from their homes – no longer required because the local IT folks spun up an Ubuntu virtual machine to use instead.  I put the Waveshare SX1262 LoRa HAT for Raspberry Pi onto my Raspberry Pi, and gave it a try.  Well, had to remove the Raspberry Pi from its nice little plastic Adafruit box, because the LoRa HAT interfered with the internal ribs.

Anyway, after some fiddling, I was able to get the first stage of talking to the LoRa HAT to work… but after ser.inWaiting() said there were characters waiting at the port, the subsequent ser.read() call caused an unceremonious abort.  No message, no nothing.  I wasn’t happy with this, but after playing around for a bit, I abandoned my efforts.  Oh, well.

So, overall with the Waveshare SX1262 LoRa HAT for Raspberry Pi , it seems that the mode pins are important and have to be twiddled in order for the board to work.  That’s probably why I couldn’t make it work on USB from my LINUX computer.  That’s a problem for another time, perhaps.

Round 4

Back to the Waveshare SX1262 LoRa HAT for Raspberry Pi .  With manually twiddling the pins, I can talk to the RF module in configuration mode, and got it to respond.  There seems to be a “temporary” configuration and a non-volatile configuration.  Even when I’ve written the parameters I want to non-volatile configuration, then unplug, switch mode bits to talk through the radio, and have the Reyax RYLR896 module chattering away beside it, I get nothing.

What I have is one Reyax RYLR896 module set as Network ID 6, Node ID 10, alternating transmissions to Node IDs 20 and 30 (yes, in decimal – I checked).  Then I have a second Reyax RYLR896 module set as Network ID 6, Node ID 20, receiving the alternate transmissions.  So, I set the Waveshare SX1262 LoRa HAT for Raspberry Pi set to what I think is the same frequency, and as Network ID 6, Node ID 30 (0x1E)… and receive nothing.

I’m not absolutely sure they are set to the same transmission parameters.  I see no way on the Waveshare LoRa HAT to set Bandwidth, Spreading Factor, Preamble, or Coding Rate.  Hmm, and the frequency is 850.125 MHz + ((0 to 80) x 1 MHz) – so I set it to 915.125 MHz.  Does the 0.125 MHz offset matter?  Argh!

The EByte E22-900T22S RF module , which is the RF module on the Waveshare LoRa HAT, has documentation which is rather sparse.  It documents only 9 registers to set (although it does show all the bit settings) from locations 0x00 through 0x08, and then another 7 bytes of identification at 0x80.  I cycled through the entire space from location 0x00 through then end of the identification.  I found several more non-zero values up to location 0x17.  Perhaps they hold the key to interoperation with the Reyax RYLR896… then again, maybe not.

Read out registers:
0x0000: 00 1E 06 60 00 41 00 00  00 00 00 00 22 14 16 0B
0x0010: 00 00 08 08 C2 03 01 63  00 00 00 00 00 00 00 00

0x0080: 00 22 14 16 0B 00 00

I went to the datasheet for the Semtech SX1262 radio chip that’s inside the Ebyte E22-900T22S RF module, just to see if maybe if I could infer more from that – if the existing E22-900T22S commands were reflected in the SX1262, there might be details of other commands.  Apparently not, the structure is completely different.  It makes sense, because the SX1262 communicates solely by SPI interface… and the E22-900T22S talks by async serial – so there must be a chip inside there to do the interpretation, and perhaps other things in the protocol.  I do seem to recall seeing something about this MCU, but from the Ebyte E22-900T22S documentation, it does not appear to be exposed to the outside world, so working on that could be a severely uphill battle.

Oh well, I’m honing my Python serial skills, and almost ready for the other modules to arrive – Seeed Systems Dragino LoRa/GPS HAT for Raspberry Pi should be here this week – the package is currently in Cincinnati, OH, at the DHL warehouse.  Apparently, the two pieces should arrive on Tuesday.  I hope so – I had to pay duties & fees on it 🙁    I will still have to switch the radio module on both pieces – although I might test it at the (wrong for North America) frequency of 868 MHz first.

The Ronoth  LoDev has not shipped from CrowdSupply after a week; I suppose that means that it’s not in stock in their warehouse…  or maybe this COVID-19 trouble has got them waylaid.  That’s unfortunate, because I see the S76S module on the LoDev as the ultimate long-term solution – it has the MCU on-board, I can program it, it has a good example, and can support USB – well heck, maybe the LoDev itself would be the CM replacement.  Anyway, it could work well in both the RMM and the remote in-the-ice measurement “puck”.

Next Steps

The RFM95W Approach

The Seeed Systems Dragino LoRa/GPS HAT for Raspberry Pi has the European frequency LoRa chip on it but the same footprint as the North American frequency HopeRF RFM95W module, which I have here.  I can switch the modules so that the unit is on North American frequencies, then put this onto the Raspberry Pi, load up the Github code to do LoRa and try to talk to the Reyax RYLR896.   I’m not sure if this will lead to a viable solution – it would be more economical to buy Reyax RYLR896 modules and add the EFM8UB2 Universal Bee to translate between the silly “AT” commands and the old Linx Technologies FHSS protocols.  I’d like to replace the STMicro STM32L151 MCU on the RYLR896 board, but the code doesn’t seem complete – looks like it might be a bear to get up and running… might be worth the trouble, if I could maybe just reprogram the STM32L151 MCU to do the whole job and emulate the Linx Technologies FHSS protocols directly (instead of “AT” commands).

The S76S Approach

Assuming that I can get the LoDev from Ronoth to talk, and can program the MCU inside of it, then I could develop a version that would emulate the old Linx Technologies FHSS protocols inside the MCU.  That MCU has USB capability, so it could be a single-chip solution for a revised Collector Module (CM) and still talk to the legacy MS-Windows software using this emulation.  On the other hand, it also has async serial capability, so it could be a single-chip solution to replace the Linx Technologies FHSS modules inside the Remote Measurement Module (RMM) without changing the programming of the Microchip MCU inside it, again using this emulation.  Thirdly, the S76S chip has I2C and SPI capability, and it’s tiny, so with a temperature sensor, it could become the basis of a new “puck” to be buried in the ice as well.

Common Ground between the Approaches

Since both the Reyax RYLR896 and S76S modules have the Semtech SX1276 RF chip inside, it’s also possible that they could both be interoperable with each other… although, based on my recent experience, I won’t hold my breath on that.  Having options is always a good thing!

Beating Up on Some Existing Ones a Bit More

I might work on the Waveshare SX1262 LoRa HAT for Raspberry Pi a bit more.  I seem to recall that I got it to answer to my settings etc., but upon further review of the Python code, maybe I didn’t 🙁  I should review again.

A second review of the Ronoth LoStik shows that its settings aren’t so much different than the RYLR896.  Maybe I need to revisit this one.

STMicro ST-LINK Debug Adapters

I’ve also got 2 different ST-LINK/V2 debug adapters – one “official” STMicro one, and one cheap knock-off (because it arrived quicker and was really inexpensive), so if I could figure out how to set up the whole STM32L151 development environment to reprogram the Reyax RYLR896, I could do that.

Filipe and I have been looking into expanding and extending the Eye on the Ice(tm) system for Hans Wuthrich of Ice Consultants International.  The original system was developed around 2008/2009 by my team at Norscan Instruments Ltd., back when we were diversifying our product offering.  I was Product Development Manager with a fantastic group of very talented people working with me.   They did a great job of the design of the Remote Measurement Module (RMM), the Collector Module (CM), and the MS-Windows software that went with it.  It’s a great system!

Alas, RF modules eventually go obsolete, and the ones used in the Eye on the Ice system will likely soon be unavailable.  They might be around for a few years, who knows, but the writing is on the wall – technology changes, RF emissions regulations tighten, and products change.

Last fall, and into the new year, Filipe and I did a proof-of-concept for an in-ice Eye on the Ice sensor which would use Silicon Labs Zen Gecko EFR32ZG14, the Zen Gecko.  Although the system did work, we found that the low-level control of a mostly-asleep sensor was going to be a huge job.  The examples given, and the information provided, just weren’t enough to get us over the challenge.  In addition, the Z-Wave devices appear to “retry themselves to death” if the central station goes away – not a good thing for a low-cost, sealed temperature sensor device.

One thing that looks like an interesting alternative is the LoRa system – long range, low data rate, adaptable for different jurisdictions.  Probably an excellent alternative for transmission of data like Eye on the Ice.

There are modules available to test – look at the Reyax RYLR896 LoRa Module at Amazon, a LoRa Hat for Raspbery Pi at Amazon, a LoRa USB stick at Amazon.  There also seems to be a LoRa book, but it has bad reviews.

The Reyax web site has a few interesting LoRa modules.  Their modules use “AT commands” to set centre frequency, spectral parameters, and data rate.  With that in mind, these modules could almost be a drop-in replacement for the present Linx FHSS modules that Eye on the Ice uses!

The RYLR896 LoRa module from Amazon is documented here – along with specifications for the “AT commands”.  The board-mount module that it’s based on is the RYLR890 which is documented here.

The MicroChip (formerly Atmel) LoRa offerings are also interesting.  There is the R34, a low cost BGA SoC that has a 32 bit ARM plus a multi-band LoRa radio.  It’s available on the cool DM320111, a US$99 reference design / development kit, also available from Amazon for the same price.  One concern is that the documentation talks about the LoRaWAN protocol stack, which we’d want to turn off, so we can just talk simple serial from station to station.

Then I found the Hope RF series of LoRa modules, very interesting, especially the RFM95W.  It looks like it’s just what we need.  It does simpler modulation as well, just by flipping a bit in its configuration.  You would lose all the error correction hyper sensitivity, and built-in spread spectrum, but it would be an easy way to establish simple communication. There seems to be plenty of documentation on the chip, the RF95.  If you Google “HopeRF RF95”, you will find RFM95_96_97_98W.pdf on the SparkFun web page, which gives comprehensive documentation of the chip, its operation, and its registers.  I suspect SparkFun stocks, them, and Digi-Key has them as well.  There appears to be a nice Demonstration Kit, the RFDK_RFM95, but I can’t seem to find a vendor…  GorillaBulderz in Australia lists them but has no inventory, and no indication of when it will be in stock.