Using the Adafruit Feather M0 LoRa (RFM95) and TTN

Entwicklung / Development Funkinfrastruktur / Wireless infrastructure
, ,
22

Yesterday I transmitted the payload from the node to the gateway as CayenneLPP encoded data which reduces the payload to about half compared to JSON. The only drawback is that I can’t influence the decoded data format at TTN. Variable names are then a bit more generic, e.g. temperature_1 or analog_in_1. Subscribing to the TTN MQTT Broker returns per variable submissions, e.g
hiveeyes/devices/thias-hive2/up/temperature_1 18.3
hiveeyes/devices/thias-hive2/up/analog_in_1 54.6

The Hiveeyes broker returned the remapped subscriptions too. Unfortunately the variables did not show up in the Grafana data source. Why? I noticed @gtuveri is also sending data this way to the backend (hiveeyes/kh/#).

2 Likes
23

Excellent!

Hi @Thias, while i didn’t have a look what’s going on on the wire by subscribing to MQTT yet, just a quick idea: Did you account for the “/data” suffix, which is required just after the CHANNEL part and before the telemetry field name of the whole MQTT topic string as outlined in the documentation at MQTT » Single readings?

If this detail is correct, please give me a short notice. Then i will try to catch some time for looking under the hood.

24

I only saw the data coming in when subscribed to hiveeyes/kh/# which has the data suffix missing and thought this is how it was sent from Guiseppes setup. Is there a conversion taking place on the broker? Probably not. I’ll suspect the missing level in the topic made that attempt fail. Both, data and measure are valid?

$ mosquitto_sub -h swarm.hiveeyes.org -t 'hiveeyes/kh/#' -v 
hiveeyes/kh/cfb/hive1/measure/weight   89.504
hiveeyes/kh/cfb/hive1/measure/broodtemperature  33.8
hiveeyes/kh/cfb/hive1/measure/entrytemperature  14.3
...

btw: I switched back to JSON and my original bridge, so no reasonable MQTT debugging at the moment.

25

Just a little note for your information: “kh” is @karsten’s channel. He runs an ancient version of the node-wifi-mqtt firmware from January 2017, which we didn’t want to break after api refurbishing took place before opening our infrastructure around April/May 2017.

“measure” was the old infix, which is deprecated but is still working for backwards compatibility. See also:

So, “/data” should be the designated infix topic segment used to separate the channel address and the field name. We aligned this to the “/data.json” topic suffix used for MQTT » Multiple readings and believed this would be a good idea before the official release. Does this make sense to you?

Sorry for the initial confusion on your side when listening to the wire.

1 Like
26

Hi @clemens
thanks for this post here and many other on different sites.
looks like you been through what I’m doing now already.

I’m trying to do exactly your setup, a LoPy as a gateway and a Feather M0 as node.
I have the Lopy working(detected on TTN), but I’m still struggling a lot with the Feather.
looking at different post you mentioned, it’s seams very vague and can’t find a single source that will work on TTN+Feather MO, with added wires and see the serial prints. I have now more than 30 tabs open and getting a bit crazy.

Here is what I’ve done.

  1. soldered down missing connections with micro-controller and the transceiver, same as image found in here

  2. changed the clock frequency to 8Mhz

  3. using the library arduino-lmic-master
    extrapolated the change needed to be done in config.h, since I’m in Canada. 900mhz…
    #ifndef lmic_config_h
    #define lmic_config_h
    #define CFG_us915 1
    #define CFG_sx1276_radio 1
    #define US_PER_OSTICK_EXPONENT 4
    #define US_PER_OSTICK (1 << US_PER_OSTICK_EXPONENT)
    #define OSTICKS_PER_SEC (1000000 / US_PER_OSTICK)
    #define LMIC_DEBUG_LEVEL 0
    #define LMIC_FAILURE_TO Serial
    #define USE_IDEETRON_AES
    #endif // lmic_config_h

then the Telenor tutorial can’t be used much since I’m using TTN…
Ive found that the application config page on TTN allow me to press a button and reverse the addresses, I’ve used the LSB ordering, witch should match since in the LMIC note it mention that the last bytes should be 0x70… so I took LSB odering and the last byte is 0x70…
used the same order for APPEUI, DEVEUI, and my APPKEY…

I also changed the pins maps, but it’s not clear if I’m using the right one for M0.
note I soldered down exactly like telenor web site shows.
here is mine;
const lmic_pinmap lmic_pins = {
.nss = 8,
.rxtx = LMIC_UNUSED_PIN,
.rst = LMIC_UNUSED_PIN, .rst = 4,
.dio = {3, 6, 11},
};

I was able to install, flash the update to the board, once it done uploading, the board is not reconised anymore, … until I double click on the button.(then IDE/computer detect it and I’m able to reflash it). but I can’t read the serial since arduino IDE will show no COM ports ( nor my windows 10 device manager list )

I’m using a laptop as well, last thought before posting his question is maybe I don’t have enough to power the board + radio directly…

so yes I’ve done my research, but I’m here stuck.
any pointers will be much appreciated :)

Thanks much

27

@gmtl nice that you will use the same hardware I have started working on.

I think your pin definition is still wrong. May you try the definition in my first post in this thread and change the reset to rst = 4,

As I mentioned the serial output is a bit tricky, see my comments in the same posting under “Some Hints”. The Feather uses two different ports for uploading and serial ouput. So after uploading the port you have used will disappear and with a establised serial communication the new port will be shown. This is very confusing first in case you know the normal behavior from the Uno boards. I think I have worked with two Arduino IDE instances in parallel one for uploading and one for the serial console.

Perhaps the second (serial) port does not show up till now because your pin definition or other things are wrong and it comes not to the serial output code till now.

28

It’s a while since I worked on my LoRa setup, but I have the additional line in my config.h:
#define LMIC_PRINTF_TO Serial

…along with this change to src/hal/hal.cpp

Also, which example did you derive your scetch from? the APB or OTAA version?

I haven’t worked with a single channel gateway yet, but I thinks it’s important to limit the channels the node is working with to the one that is supported by the LoPy gateway as described here.

1 Like
29

I’ve used the OTAA model
I’ll test your suggestions and see if reducing the chanels can fix it.
at least someone in my area sent a message via my gateway…:)
I’ll keep you posted.

not so sure what would be the chanel# I need to use… I know it’s 915 but
I see Andreas is in Europe and removing all chanels except ‘0’…
I can’t find the list of equivalency,

30

In case you have any trouble I would use ABP first. You need a downlink for OTAA. So it should be technically easier to use ABP.

for the LoPy as gateway see also LoPy - Triple-network WiFi, Bluetooth and LoRa dev board and LoPy with TTN Nano Gateway and Arduino (and RFM95) with LMIC lib | Pycom user forum

31

Looking at many post everywhere I found a fork here
https://github.com/matthijskooijman/arduino-lmic/tree/non-avr-printf

should this one fix the serial print issues ?

have you guys used the original or branches ?

I’ll try the ABP method tomorrow and keep you posted :)
I’d like to finally move forward and eventually test the loraserver.io instead of TTN :)

32

We used GitHub - matthijskooijman/arduino-lmic: LoraWAN-in-C library, adapted to run under the Arduino environment as posted in #1 of this thread.

33

Yes , to second @thias and @clemens! ;)
Also see my posting here in this forum (Problems getting Adafruit Feather M0 LoRa (RFM95) running - #11 by weef), so using the non-avr-printf branch is for exacly this.

34

I just realised that I got a different board.
I was sure I got the RFM95 radio… but it’s this one instead

it’s based on the RFM69 !!!

do you guys have tested this one yet ? any reason I should swap the radio on it for a RFM95?

35

;) erm… depends. If you need to run LoRa, then you need the RFM95 (or RFM9x) - this type of modulation the RFM69 isn’t capable of. If you are fine with the FSK and OOK modulation types the RFM69 offers (furthermore GFSK, MSK, GMSK) then stay with it.

1 Like
36

Ok, that makes a lot clear! ;-) For LoRa and or TTN you need the 95 version!

37

I’m thinking of desoldering the hope module and replace it for the RFM95 instead.
it should not be so hard with hot air and good neighbor master soldering who can help.

this time I want to be sure I get the right one ahhh
looks like this version of the hope module is the one…
https://www.digikey.ca/product-detail/en/rf-solutions/RFM95W-868S2/RFM95W-868S2-ND/5051755

I’ll probably end up buying more feather neways.

38

Hi guys,

looking around, I found a very cool board that include a STM32L07 and a SX1276.
made me look at the ‘many’ LMIC forks and origins… made by IBM earlier but from the github I see that no new commit where made since 3 years ago… but in a sub directory I see that they have made a ST32 folder… would that be the one I should try ( once I receive my new ordered boards ).
or the lasted non-avr should be considered?

and I,m curious if any of you has tested the https://www.loraserver.io/ ? ((that might be useful to start a new post for that question…))

Thanks

39

What board is it, do you have a link?

Yes, good idea!

40

here is the board ;
http://arxtech.ca/produits/components/iot-motherboards/arxtech-lorawan-module.html

and I’ll post a new tread on the server… ;)

41

In case you have the Feather 32u4 already on your desk, have a look at at the condensed TinyLoRa lib GitHub - adafruit/TinyLoRa: LoRaWAN Library and the documentation https://learn.adafruit.com/the-things-network-for-feather/tinylora-usage .

1 Like