I ‘almost’ got it to work: the software compiles, I have made the necessary hardware connections on the board, made al the proper changes to the software for pin definitions, Lora keys, etc.
When I turn on the device, it succesfully sends the ‘hello world!’ message to TTN just once and then it seems to hang, or it is waiting for something (and ack from the network?). On the console, I only see:
Starting
Packet queued
And nothing more. I suspect the problem is in the radio part, but that is seemingly time critical software because all changes I make there for extra debugging only seems to make it more unstable.
So I’m curious if others have run into the same problem, maybe already fixed it or may give me some pointers on how to proceed.
I would be interested in this too - I have had no problems getting LMIC working on Unos but on other devices like the moteino or the rocketscream and I’ve not managed to succeed.
Any input or assistance would be appreciated here too.
Hi @iot-partners, Hi @johnmiddleton, I have this working with a 32u4 and an extra RFM95 module board. Can you give me the details on your DIO pin connections (hardware, https://www.adafruit.com/products/3078 ??) and the lmic_pin const? Cheers
Since DIO0 is already wired on the board to D3, RST is wired to D4 and NSS is wired to D8, I only hooked up DIO1 (to D6) and DIO2 (to D11). I’ve read in other threads that DIO2 is not stricktly necessary for LORA operation but I wired it up anyway, just in case. So my pin settings are:
@johnmiddleton, It’s an interesting issue, but on the other hand, I don’t use OTAA and I am not sending any data upstream to the mote, so I don’t know if that timing issue on the rx window could be the problem on my device.
Hi @iot-partners, @johnmiddleton, The problem is that DIO1 is NOT connected to pin 6 on the board (according to the schematic of Adafruit). This bit is used to check ‘ready for the next transmission’. So, only one transmission, and then it will stop. The text from Adafruit: #8 - used as the radio CS (chip select) pin #7 - used as the radio GPIO0 / IRQ (interrupt request) pin. #4 - used as the radio Reset pin Since these are not brought out there should be no risk of using them by accident! There are also breakouts for 3 of the RFM’s GPIO pins (IO1, IO2 and IO3). You probably wont need these for most uses of the Feather but they are available in case you need 'em!
So connect IO1 (DIO1) pin to pin 6. Do not use pin 11, not needed, so LMIC_UNUSED_PIN there.
Cheers
But that is exactly what I wrote: I wired up DIO1 to D6 !
So now I uncoupled IO2 - D11 and put LMIC_UNUSED_PIN in the pin connections instead of D11, but the result is still the same… hanging after the first transmission
Just checking :-). Look at Adafruit LoRa Feather -> Gateway , i saw you posted your question also there. But my advice remains the same. I use OTAA, the mentioned library ( https://github.com/matthijskooijman/arduino-lmic ) , and the ‘out of the box’ example. Blinking a led on the digital port has solved many problems (interconnection, wrong pin numbers etc). The symptoms look so familiar, i solved it by checking the DIO connections (only DIO0 and 1 are needed).
I have very similar results with the M0 version: Adafruit LoRa Feather -> Gateway
If both the M0 and 32U4 platforms have the same or similar issues, then i suspect the LMIC library might be to dependent on the Atmega328P. Has anybody got it working on an non Atmega328P processor?
I have some issues with the M0 and outputting to serial port. This makes it very hard to debug. I have spent many hours trying to figure it out, but no luck.
Same here @sillevl very hard to generate debug info on the serial interface, and also tried blinking the onboard LED to see where things get stuck but that only makes it more unstable…
But then @Galagaking has got it working on this architecture, so there is hope. There is only very little configuration to do to get it running out of the box, so where do we go wrong…?
To create even more mystery on it for you guys: the same setup is working for me on a M0 feather! I got messed up with several LMIC versions, I have cleaned up all my libraries, did a re-install of Arduino IDE. I did have problems with Visual Studio to create a working setup. May be you can look at that? Downloaded the library from @matthijs as mentioned above , change pin numbers, and it works. I use a breakout board for the RFM95, so I connected in another way. M0 / 32u4 setup is the same:
// Pin mapping
const lmic_pinmap lmic_pins = {
.nss = 10,
.rxtx = LMIC_UNUSED_PIN,
.rst = LMIC_UNUSED_PIN,
.dio = {5, 6, LMIC_UNUSED_PIN}, //
};
The first OTAA cycle will last long (3-4 mins), but then I sent every minute a frame without a problem. Hope this can be helpful.
@sillevl , The M0 serial port IS terrible. I switched to Serial1, connecting via a normal FTDI connector and not through this USB simulation stuff. Replace all the Serial statements with Serial1 and (debug) life is a lot easier!
@Galagaking I will try if your pinmapping makes the difference (this weekend). Will update with the results.
Did you change the spi fequency in the hal.cpp file? I have some FTDI breakout boards, will try that again as well.
Congrats! Had some thoughts about your problems. I use 10E6 (default) in hal.cpp, because i did a new start with the clean LMIC library. The Serial / USB port emulation was driving me mad. So I changed everything to Serial1 (connect FTDI to RX0, TX0). For experimenting my ‘wifi FTDI’ ESP8266 Serial to Wifi setup was extremely helpful (https://github.com/jeelabs/esp-link). By debugging this way, things were much more stable. I think there is some interference between the USB / Serial code and LMIC. At this moment my node only stops when the LIPO is empty! Cheers
For me still no luck, while I seemingly have totally identical setup to @sillevl : same pin mapping, same HW connection from DIO1 to D6, using ABP, SPI clock changed to 8E6… And still it only sends data once and then stalls… Driving me nuts!
@iot-partners did you remove all the references to Serial? I changed them all to Serial1 and used an FTDI breakout board as external Serial to USB converter. I am not sure, but I think this makes the difference.
very hard to generate debug info on the serial interface, and also tried blinking the onboard LED to see where things get stuck but that only makes it more unstable…