I'm running the ttn example from the LMIC library on a arduino UNO. I am using a Semtech SX1276mb1mas board and a level converter between the arudino and the semtech board. But when trying uploading the ttn example to the arduino i get the following in the serial monitor:

What does it say on that line with your library version? What version of LMIC are you running?

I suspect the failure happens at this line:

ASSERT(v == 0x12 );

Where it checks if the transceiver responds with the correct hardware version. This either means that the transceiver is incorrect, or the SPI connection is not working properly. You should probably check your wiring, and perhaps lower the SPI speed (see this pull request: https://github.com/matthijskooijman/arduino-lmic/pull/27).

Thanks for the answer, it is very appreciated!The command is:u1_t v = readReg(RegVersion);

Im using LMIC 1.5. Where can I find the SPI settings? There is nothing in the config.h file. And also, should i use the ICSP header or pin 11, 12 and 13 on the UNO for SPI?The chip is a SX1276 in a SX1276MB1MAS shield.

Just for others encountering same problem. There probably is an SPI connection not correct.

I'm running the ttn example from the LMIC library on a

arduino UNO. I am using a Semtech SX1276mb1mas board and a level converter between the arudino and the semtech board. But when trying uploading the ttn example to the arduino i get the following in the serial monitor:

I just pushed a big update to the lmic library. * All changes that used to live in the experimental "mjs" branch are now cleaned up and merged into master. This adds an OTAA example, replaces the default AES implementation by something that's smaller and adds compensation for clock drift (manually configured using LMIC_setClockError() from the sketch). * I've merged most of the pullrequests that were submitted, except for two that need some more thought and/or testing. This improves 915Mhz, adds proper parsing of the RX2 datarate from the join accept (no further need to set LMIC.dn2Dr when using OTAA), fixes the DevStatusAns MAC response and improves compatibility with the ESP platform. * I added some more bugfixes to the OTAA code that could cause OTAA, or the first packet after a join, to take a lot longer than it should. I also added some debug output to the library (enabled by LMIC_DEBUG_LEVEL in config.h, don't forget to also set LMIC_PRINTF_TO.

Thanks to all the people that contributed patches or suggestions. My apologies for not merging things sooner, but it's great to see so much great quality contributions here!

In other news, @Thomas and myself have been in contact with Marcus Oestreicher, one of the developers of LMIC at IBM. IBM is no longer working on the LMIC code, so the plan is to move the "upstream" LMIC development (as opposed to my arduino-specific port of it) to github as well, maintained by (initially) Marcus, Thomas and myself. All non-Arduino-specific changes in my repository should be merged back to that repository. This should allow other (non-Arduino) users of the library to profit from our work, and vice versa.

On my request, IBM has also agreed to change the license on their code to the three-clause BSD license instead of the Eclipse Public License that was used before. This should make it possible to combine the LMIC library with GPL code or other licenses (including propietary code). I hope this will make LMIC a viable option for more people and projects. A direct gain of this is that the AES libraries that I considered to integrate are now no longer blocked by the license, so we'll likely integrate AVR-AES as well. The license change has been approved internally, and as soon as I've reviewed the proposed changes, a new tarball will be published on their site.

May be a good approach would be (as RadioHead lib is doing) determining the platform used (RPI, ESP8266, SAMD, 328, ..) in a include file (limc.h or platform.h or other) so we can conditional compile in code later. I can start on this if you agree ?

Tell me if you think it's not the best solution or just if you have another one.

May be a good approach would be (as RadioHead lib is doing) determining the platform used (RPI, ESP8266, SAMD, 328, ..) in a include file (limc.h or platform.h or other) so we can conditional compile in code later. I can start on this if you agree ?

Well, the intention of my repo is to run on Arduino, and hal.cpp uses mostly platform-independent Arduino functions (so effectively, Arduino is the real HAL). So In that usecase, there would not be much conditional code needed at all.

@matthijsThanks for your answer, in fact that is exactly what I already done, conditional compile and there are not "too much", what I've done is creating a raspi.cpp and raspi.h exposing Raspberry PI low level such as digitalWrite, millis(), micros(), Serial, .... using bcm2835_lib and of course I added samples, one is using Network MAC address to generate dynamic devEUI on otaa sample code

The only file I changed (but I added some) is hal.c because managing I/O is quite different on Raspi with bcm2835 and also SPI setup need clock divider and not speed.

But I think I'll move to WiringPi to be able to have a kind of 'attachInterrupts()' to we can really be waked on interrupt and not checking DIO line or RFM95 register in loop (We already had a talk about this one) because we're on a multi-tasking system and we're proud enought not taking all CPU waiting for an level change on a line

Anyway, I've pushed a specific branch called rpi I still need to solve some problem but you can take a look of what is currently under development (I also updated the readme for Raspberry PI installation)

I have the latest update running on a Teensy LC with an RFM. Thank you very much @matthijs.The sketch runs on a node that I use as a battery-powered pinger on TTN mapper and I do not plan to run it continuously and break the fup. I've tried to find in the code where I can make it transmit more often than the current once per two minutes by changing these lines in the send-v1 example:// Schedule a timed job to run at the given timestamp (absolute system time) os_setTimedCallback(j, os_getTime()+sec2osticks(120), do_send);into os_setTimedCallback(j, os_getTime()+sec2osticks(10), do_send);But that does not give me 10 seconds transmissions, in fact it seems to hang when I do that.