Big LoRa32u4 boards topic

#179

Hi everyone,

i trying to get a bs france Lora32u4 II board to run. Board version is 1.3(!) and it seems to be different than the 1.2.
First of all, i’m not sure which version i got. I want 866Mhz.
On the back there are two white boxes, one saying 866MHz and one 915MHz but there is no mark which one it is.

Even more confusing, after uploading an example Sketch, in the arduino IDE it says: “Port /dev/ttyACM1 Lora32u4 (433MHz)”

I followed as far as possibe those instructions: https://www.youtube.com/watch?v=0dfMrWHWmqw but i didn’t solder anything because there is only one solder pad on the back instead of three.

So my question is how can i find out which frequency is used. and second how can i see if the connection to the gateway is working? The next gateway is around 1.5 kilometers away. Is it possible with this board?

Thanks in advance

#180

Forget to mention: Of course i selected the 866-915MHz version in the Board selection.

#181

Read the extensive information in this thread first before asking other forum users for help.
This thread is not intended for providing help for instructions in other people’s Youtube videos!

Both V1.2 and V1.3 are clearly described in this thread, including their differences and instructions how to get the board up and running.

If you do not want to solder DIO1 then you might try example ttn-abp.ino to use ABP.
That should probably work without DIO1 connected, ttn-otaa.ino will not work without DIO1 connected.
For normal (OTAA) operation you will have to connect/solder DIO1 anyway.

If the board says 868/915 MHz then it probably is.
It is possible (but less likely) that a 433MHz LoRa module is mounted on the board.
I find it unlikely though that the Arduino IDE would be checking whether the module is a 868/915 or 433MHz version. The 433MHz message may possibly be incorrect (caused by USB driver).
I have no experience with Arduino on Linux or OSX, but when I connect my LoRa32u4 V1.2 to a Raspberry Pi then lsusb shows it as ID 239a:800c without LoRa32u4 and without frequency. This may be different for V1.3 though (I have none to test it).

#182

Thx for your reply.
I got it to work after some time. On the first post, i didn’t see any information about v1.3 so i thought there is no.
There are not many guides how to get startet with this board so i reffered to the one on youtube to make clear what i’ve already done.

DIO1 is connected by default in v1.3 so its not neccessary to do anything here.
lsusb shows 230a:800c in programming (boot) mode and 239a:800c during normal operation.

Additionally i had an error from the IDE because of a missing hex file. Was just a typo of Lora and lora so i need to rename the file.

Last it seemed as if the device could not register to the network. I got this message for i guess 30minutes
8715102: EV_TXSTART
9108467: Unknown event: 20
then it finally starts sending. Wohooo \o/

#183

Good to hear that you got it working. :+1:

Ah yes, of course.

I already wrote the following before: :blush:

#184

I have updated the topic start and added information for:

  • LMIC Pin Mapping.
  • LMIC Timing (LMIC_setClockError()).
  • BSFrance LoRa32u4 II version 1.3.
  • MCCI LoRaWAN LMIC library as replacement/alternative for LMIC-Arduino.
1 Like
#186

How about this “miniaturized version” of LMIC that was presented in this topic?

#187

Based on the repository URL in the post you referenced:
The provided lmic_slim library:

  • Lacks any documentation .
  • Lacks any references.
  • Is provided only as a zip file which appears to come from elsewhere (no repository).
  • It is unclear what is and what is not supported by that library.
  • It may very well not be LoRaWAN compliant.

It got an impression that it might be based on TinyLoRa but I don’t know (I have no experience with TinyLoRa).

1 Like
#188

Yikes! Not that great :confused:
Too bad, the lack of memory space is IMHO biggest LoRa32u4 drawback.

#189

No, a lot is uncertain about the lmic_slim thing but the actual code closely resembles LMiC in the style and naming of functions and structures, making it look like a very stripped down version. It’s also functionally C code of non-Arduino heritage.

TinyLora is fundamentally C++ code of very different internal details. TinyLora also has some degree of history and ownership clarity.

The provided functionality does however seem to be very similar between the two - while lmic_slim has a receive function, it doesn’t actually appear to have the other things needed to receive, like timing or packet parsing and decoding.

2 Likes
#190

Hello Excuse me english, I want to know if the board Lora 32u4 ll v.1.3 supports Class C and if LMIC also supports class C
Thanks.

#191

Those are perhaps interesting questions to research on the commit and issue history of a given LMiC repo.

But as TTN does not support Class C, they are perhaps not very relevant questions to ask here.

To an extent modifying a node firmware for class C is comparatively simple - in effect, instead of going to sleep you just start the radio going with appropriate settings. Mains power is a practical requirement to leave the radio running.

#192

My friend Dennis built this lmic_slim in 2017 from an early copy received from René Harte. It would by nice to collect your suggestions and finally do the work to make it more usable to the community. From all your feedback it seems to me there is so much knowledge missing on my side.
Would it be worth to you to get the lmic_slim to a better level, or did better alternatives become available?

For me, I still love this board, running it as gps tracker, temperature, noise, particle matter measurement. Using this in my monthly training ‘IOT for Beginners’. I want to add training material online, so all of you can give such training to your community as well. Interested?

Recently added some quick and custom map and graphing integration. This is all built serverless with Amazon Lambda and S3. Under the covers this adds a big data feature as well. I like serverless as it changes the way of thinking for many. I want to document this code as well and make it available to all of you. Help is appreciated to set it up correctly to make it improve and grow with your community input.
Temperature graph example: http://junioriotchallenge.nl/graph/?dateStart=20191209&dateEnd=20191212&application=junior-iot-in-a-box-project&device=all&values=BME280_Temp

Please send your guidance on improving the lmic_slim library!
Marco@juniorIOT.nl

1 Like
#193

Hi Marco,

Thanks for your lmic_slim feedback.

In short: My feeling is not really because:

further:

  • I’m almost certain that lmic_slim is not LoRaWAN compliant because there is no indication of that whatsoever. It is not even clear what is and what is not supported by the library.
  • The library is provided as a ZIP file and you ask for feedback via email.
    That is not how open source development works.
  • What should people give feedback about when nothing is even documented?

That depends on your definition of ‘better’.

While 8-bit AVR MCU’s are still used there is a tendency to shift to 32-bit ARM MCU’s (and things like ESP32) that have (much) more available memory resources, are more powerful and are better able to handle a full LoRaWAN stack implementation.
Multiple LMIC libraries are available for the Arduino framework already. They will not be as small as lmic_slim but are LoRaWAN compliant, are open source and (some) are well-maintained.
In answer to “would it be worth to you to get the lmic_slim to a better level”, I guess not, unless you want to develop for a niche, have much spare time and are willing to maintain it for longer time.

#194

If you really want something LMiC derived but lightweight, your best bet would probably be to work out a series of #ifdef’s to remove what you don’t want at compile time. But keep it based in git and tied back to an actual LMiC. To some extent you don’t even really need to drop code (the linker will do that) but alter the control flow.

Implicit in that would be really deciding and documenting what you aren’t supporting. For example in the current version it doesn’t look like the code has logic to try to receive or to parse received packets, but it still has some of the receive functions even though it’s missing the ones that would be needed for those to be of any use.

#195

Hello, excuse me english I use the lora 32u4 ll v1.3 in AU915 and library mcci-catenna Lmic, my Sketch is very big and I need to reduce the size, I do all the necescesary for reduce the size in the sketch and also I delete some files like the bandplands that I don´t use but still very big. someone knows how can I reduce the size in the library ? Thanks for your help.

#196

Deleting files that aren’t used won’t really do anything, the linker should already be removing code that is never referenced. Try finding the elf output wherever the IDE is dumping it (probably somewhere under /tmp) and using the appropriate avr objdump to analyze the contents and see what is taking space.

I have seen situations on other platforms where strings for debug messages were being included in the build output, even though no code that every referenced them was.

Ultimately though you may need to reduce functionality or change to another chip. This is asking a lot out of an basic-tier ATmega, most users of LMiC are on ARM parts or ESP8266.

#197

In case of changing to another chip, ESP8266 would not be a good choice because of its limited available GPIO pins. Its more advanced successor ESP32 is preferred instead.

#198

Hello bluejedi thanks for your answer. I think should change mi Lora32u4 by the rak811. Do you think its a good idea ?. However I resolved the problem acorrding to your indications using PlatformIO.
thank you very much

#199

I have no experience with RAK811 but it contains a STM32L151 MCU, not ESP32.
It can be controlled via serial interface using AT commands which requires a separate MCU for the application and it can also be used standalone in which case custom sketches can be uploaded.
Development seems to be based primarily on the Arm Mbed framework. Arduino Core STM32 shows (basic) support for RAK811 so it appears possible to program it using the Arduino framework and LMIC (but I am unaware if that is actually being used much).

There is no simple answer to what would be good alternatives for LoRa32u4 because that depends on one’s use case(s) and requirements. (To stay on-topic it is preferred to open a separate topic for discussing possible LoRa32u4 alternatives.)