At worst, you can skip the D1 as reset so you have D0 for NSS/CS and D1/D13 for the DIO0 & 1 and rely on board reset at power up.
Trouble is, that leaves you no I/O for actual sensors unless you start removing the DotStar LED.
1 Like
I like electronics and telecommunications. It’s my hobby.
1 Like
This idea may be useful for debugging actual “no JoinAccept”. I could send a simple “hello world” data. Thanks!
There are not many ARM based LoRa development boards available unfortunately.
Not sure why because ARM chips are available in same price range as ATmega328’s these days.
Some while ago BSFrance had three different STM32 ARM based LoRa boards in their product range. Due to lack of good product support and not maintaining their Arduino Core the boards did not become a success unfortunately (and first versions were not designed with true low power in mind).
Currently the Heltec CubeCell boards are quite affordable ARM based LoRa boards.
For ARM based development boards without LoRa (need external LoRa module):
STM32 based ‘Bluepills’ are dirt cheap, same price range as ATmega328 Pro Mini’s.
(But require some hardware tweaking to make them low-power battery friendly.)
The Arduino M0 mini boards with SAMD21 ARM have become more affordable in the last year but as far as I’m aware the SPI pins are only available on top as part of the ICSP connector which is a serious design flaw. It makes these boards much less suitable for use on breadboards when SPI is needed (as is for SPI based SX1276/RFM95 LoRa modules). Maybe it is possible to map the (hardware) SPI bus to different pins but I have no experience with latter. If someone knows how then please share.
Apart from a lack of consistency across the MKR range, they do provide SPI on the main pins:
A lower cost possibility is the ItsyBitsy M0:
If there is a move to using a M0 style MCU, hopefully we can find the will to fork the LMIC and implement an interrupt handler rather than the polling loop - and remove the os_job complications.
Thanks. That’s a different board.
SAMD21 M0 Mini (Arduino M0 compatible) board is like this:
Available here.
This STM32F411CEU6 board also looks interesting:
That’s truly… odd! “ICSP” is an ATmega thing, putting such a header on an ARM board where SWD fills that purpose is pretty goofy, maybe someone did it for Arduino compatibility.
There are probably hardware SPI interfaces available on other pins too, and if not one can always bit-bang, it’s not like there’s a huge amount of information that needs to be moved at blinding speed.
Yes, odd indeed.
If someone has sought that out already I would be happy to know.
The problem is that those SPI pins on top are the ones that are standard defined in the SAMD Arduino core for the M0.
I’m not aware if the SAMD21 on this M0 Mini has multiple hardware SPI ports or whether its SPI can be remapped to other pins.
And if in that case it would be possible to redefine or reconfigere the pins for the default SPI port object in the Arduino environment.
Latter sometimes is possible and sometimes is not and as far as I’m aware LMIC Arduino (without modification) only works with the standard SPI pins.
It appears that this board is just not breadboard friendly for SPI use (I don’t like that it needs separate additional wiring on top).
one can always bit-bang
I try to prevent the use of bitbanging solutions and only use hardware supported interfaces.
Latter provide better performance and the least hassle.
The board’s schematic suggests SPI on pins D10-D13 too
If that doesn’t work, I’d suggest realistically reconsidering your feelings about bit-banged SPI. In reality it’s not going to make a whole lot of difference - at most a few milliseconds in what is already a very infrequent operation.
In terms of “least hassle” I’d actually argue the opposite - bit-bang SPI is pretty easy to code up and entirely portable so often a lot easier than figuring out how to get the hardware SPI capability of a new chip going.
Well, I’m back to the topic.
I decided to not remove any LED from trinket and wait for arduino pro mini 3.3v
Today I received arduino pro mini 3.3v. I repeated the same procedure as with the first nano board and I see in the console the same no JoinAccept. Status - never seen.
The code is uploaded successfuly to arduino but I noticed this while compiling:
C:\Users\lorauser\Documents\Arduino\libraries\MCCI_LoRaWAN_LMIC_library\src\hal\getpinmap_thisboard.cpp: In function ‘const Arduino_LMIC::HalPinmap_t* Arduino_LMIC::GetPinmap_ThisBoard()’:
C:\Users\lorauser\Documents\Arduino\libraries\MCCI_LoRaWAN_LMIC_library\src\hal\getpinmap_thisboard.cpp:67:72: note: #pragma message: Board not supported – use an explicit pinmap
#pragma message(“Board not supported – use an explicit pinmap”)
^
Arduino pro mini is selected in arduino IDE like this:
Any ideas what’s wrong?
What is the type of gw and range of those (is there some ttn mapping available ?)
In very dense city like Paris, with the kind of lora module you have you have less then 200m to 300m of link.
Second, as far im french too, and running a GW in Paris suburb im not aware that Paris is fully covered by TTN gateway. And most of these are indoor gw with limited range.
So Unless you have your own GW, or you are lucky enough to have a GW very closeby, I think you will never reach a gw.
Unless you go out, walk and put your device in range.
Feel free to come closer to my GW https://ttnmapper.org/colour-radar/?gateway[]=B827EBFFFE6A3D2F
I can provide coffee 
1 Like
Somewhat unsurprisingly, neither the pro mini nor any ATmega based Arduino is a board supported in the current updated form of that project.
You can try copying and modifying one of the supported boards’s support files in the project source to fit the details of yours with an appropriate name and adding it to the selection logic that is throwing that error, but it’s probably not a worthwhile effort when your board’s MCU is so short of resources.
Use a supported board instead, or if you are going to go to the trouble of creating a port, port to something of comparable rather than drastically lesser capability.
Can you simulate “no coverage” for your device? Shut down your GW for a minute or take your device somewhere underground where no radio is available. Will you see the same “no JoinAccept” like me? If it’s possible for you of course.
Anyway, I will go out tomorrow for a next test in the area of outdoor GW.
It’s quite interesting how this guy managed to do this, without errors with the same hardware as I have now. On 15/02/2019 this example worked, then “Posted by Jonathan at November 20, 2019 09:41:40 CET” - “It doesn’t seem to work anymore.” But he didn’t specify what’s not working. Indeed it’s possible after update it breaks. I will repeat the test with the first library version until the latest-1
Another thing I observed is if I have arduino-lmic library installed, then my code is compiling with errors because of duplicate file lmic.h (this file is present in both libraries arduino-lmic and MCCI Arduino LoRaWAN Library) so I moved temporarily arduino-lmic library to avoid conflict with MCCI, but, in required libraries, it suggest me to use this conflicting library. Another stuck situation… An idea may be to keep both libraries, but to tell to the IDE to use the right MCCI library, something like #define path/to/MCCI/lmic.h
I moved back arduino-lmic library and defined full path to MCCI lmic.h and hal.h
and also installed Catena-mcciadk library - The error about “Board not supported – use an explicit pinmap” dissapeared, but no JoinAccept is still present.
To be continued…
Im not experienced with stm hardware, im mostly using esp32 lora module such at ttgo tbeam.
What i know is that if i go to the parking downstair, and switch on my module, it cannot join the network 3 floors above. I often join the network at home, and then go out once it joined, when im going out for mapping my GW range.
after that i put my ttn mapper in the car, and sometime i discover some gateway, such as the one runned by AFNIC (in SQY) which was on the path to my previous work.
Yes, you didn’t define a pin map!
Something like but not necessarily identical to:
// RFM95 Pin mapping
const lmic_pinmap lmic_pins = {
.nss = 10,
.rxtx = LMIC_UNUSED_PIN,
.rst = LMIC_UNUSED_PIN,
.dio = {3, 2, LMIC_UNUSED_PIN}, // DIO0, DIO1 - these are for the TinyThing PCB
};
in the Setup section very early on. You have to change the pin numbers to suit your connections.
See previous post:
1 Like
Pin mapping section is already present in setup section of ttn-otaa sketch. I just changed pin numbers. But this problem was resolved I think. I don’t see any error with MCCI_LoRaWAN_LMIC_library while compiling after playing yesterday with required libraries and define full/path/to.file
Just for testing, I tried your suggestion to use IBM LMIC framework - I get errors while compilling ttn-abp example. There are 2 files named hal.h (\src\lmic\hal.h and \hal\hal.h)
Because I use different LMIC libraries for testing, I need to declare full path to desired lmic.h and hal.h, else, if declared by default like #define <hal.h>, arduino IDE searches in libraries folder in alphabetic order and use fisrt file found, then I get errors. So I declared full path to lmic.h. But there are 2 hal.h I tried with first one, then the second, plenty of errors, not compiling. Switched back to MCCI_LoRaWAN_LMIC
So, you have two libraries in your Arduino libraries folder that do the same thing, the file paths get confused and it doesn’t work?
Why not just move the MCCI one out and leave JUST Matt’s one in it and compile the OTAA example with your info - takes about 30 seconds and works for me.
Until you get it working, make it all as simple as possible, but no simpler.
if defined by default #include <hal.h> - doesn’t work; if defined full path #include “C:/Users/lorauser/Documents/Arduino/libraries/MCCI_LoRaWAN_LMIC_library/src/hal/hal.h” - compile successfull.
Actions performed:
-Moved all other lorawan libraries to temp folder. Left only IBM LMIC framework
-Checked config.h - it’s OK
-Compiling default ttn-abp then ttn-otaa example without errors.
ABP: Packet queued
38948583: EV_TXCOMPLETE (includes waiting for RX windows)
OTAA: no JoinAccept
Status- never seen
It’s time to got out for a closer GW. The rain stopped.