I received my LoRa Feather M0 yesterday and started playing around. Unfortunately I did not get far. I struggled a lot with the flashing of even very simple firmwares. Most of the time the process gave errors on the /dev/ttyACM0 port. The device never opened a /dev/ttyUSB0 serial port. I’m not 100% sure if the device is fully functional from the hardware side at all. At lest and on very rare occasions I got the example firmware transferred successfully.
@clemens would you mind sharing your devEUI detection and OOTA sketches with me? That would help me a lot to figure out what goes wrong. The TTN Quick Start only returned the “-- STATUS” line. nothing more.
Thanks!
I assume that you have installed the according Arduino SAMD Boards and the Adafruit SAMD package as described in the Adafruit Tutorial under Using with Arduino IDE. There is also an advice to install some drivers.
The most helpful advice in the FAQ section was to “double click” the reset button on the Feather M0 in case uploading does not work properly!
An also enlightening part was the information that the M0 has two com ports
Theres two COM ports you can have with the 32u4/M0, one is the user port and one is the bootloader port. They are not the same COM port number!
[…]
When the user COM port disappears, Arduino will not be able to automatically start the bootloader and upload new software.
So you will need to help it by performing the click-during upload procedure to re-start the bootloader, and upload something that is known working like “Blink”
So my advice would be to double click / press the reset button on the Feather, select your COM port in the IDE and then upload your code as mentioned in my initial post under “Some Hints”.
yes, I installed the boards according to the guides. I already got familiar with the double klick reset action. I also added the udev rules. The status detection sket now gives
Think the OTAA example needs an back channel so it could be that your gateway did not support this or your node can send (gateway can receive) but your node did not get the answer. What gateway do you use?
A Potsdam based freiFunk member has a gateway at home but he’s not entirely sure about full functionality. This morning I tried connecting in front of his house with the OOTA example sketch without success. I will try the ABP version later today. There’s another gateway which I will also visit. Unfortunately, due to the distance and shielding circumstances, I can not connect to both gateways from home.
Looking at all the forum threads around it’s probably not. Although the behavior of the board looked very promising. The join procedure triggered the yellow LED in a way that looked like TX attempts: irregular blinking, longer and shorter breaks. That made me believe the firmware is interacting with the hardware.
Since I’m using the example sketches I’m on this library as well. And yes, I made all the necessary configs in the library and sketch as well as the proper wiring and checking the keys multiple times.
Could it be that the gateway is a single channel gateway? In this case the (only) channel has to be configured in your sketch and both channels - on the gateway and on the node must be the same! Also the SF parameter must be set in both devices and has to be the same.
So it would be great to figure details about the gateway out. Do you have any information?
The freiFunk gateway is an iC880a connected to a RasPi. That solution runs the LoRaWAN stack and is made for multi-channel transmissions.
The other node is listed offline as of today. I sent a request for more details on the gateway to the owner via TTN.
Debugging the firmware during runtime didn’t work for me either. #define LMIC_DEBUG_LEVEL [1|2] and uncommenting #define LMIC_PRINTF_TO Serial in config.h result in an error while compiling the firmware.
Using a greedy full-fledged printf is always an expensive problem on small machines with limited ressources. However, the lib started made for AVR, and as you run this on a Cortex M0+ and not an AVR, #define LMIC_PRINTF_TO Serial won’t work for you:
lmic_printf is defined platform-dependent in oslmic.h (L224-L263), and it reflects to hal.cpp .
For debugging on your processor I’d suggest using the non-avr-printf branch of Matthijs’ LMIC repo rather than master.
"Software efficiency halves every 18 months, compensating for Moore’s Law.” - David May’s law
But, according to TTN console the device was seen in the network (back then without the missing SPI clock fix) on Friday while I drove through Berlin. Unfortunately, both Potsdam nodes are offline at the moment.
It turned out that the node successfully transmits the test payload with the ABP method even without the change for the SPI clock error. Instead it was the local gateway that troubled me.
Thanks for your support.