Communication questions with Lora for motorcycle laptimer project

Projects General Guidance
1

Hello everyone,

I am in the process of building a laptimer for racetrack (for my friends and I) and I am really interested in (raw) Lora to share data (sector + laptimes + messages) between one or more laptimer and a base unit.

Context

I would like to use Lora to :

  • transmit the sector time and laptime from each of my laptimers (node) to a base station
  • transmit messages from my base station to the laptimers (node)
  • in a future version, maybe transmit additional informations (GPS, sensor reading)
    Update frequency will be around 1 measure each 10 to 60sec, depending on the racetrack.
    And required range is going to be arround 1km for most of the tracks.

I plan to use an Arduino for the laptimer, and either an Arduino or a Raspberry for the base unit.
I already have a first "standalone" version which I need to test, but this post is to have more informations about the Lora side.

Here are my few questions

  • First things first, is (raw)Lora suited for my (future) application ? Or is there better alternative ?
  • Is it possible to use Lora with a hidden/internal antenna (typically inside a case for the laptimer). I do not want to have an external antenna on the laptimer itself. The base could have antenna though.
  • What range is doable with such hidden/internal antenna?
  • Is it possible to make an antenna directly on the PCB?
  • Which hardware is suggested for my application (on laptimer) ?
  • Will a Raspberry Pi will work as a base station?
  • What update frequency could I reach with Lora? In the first prototype, I only need the data each 10 to 60sec, but is it possible to refresh the data more often (1-2 second for a GPS position for example) ? or is it already too much?
  • Which frequency should I target ? 433Mhz or 863-870Mhz (I am in Europe)
  • Power consumption is ok for use on battery?

Thanks a lot if you have answers or feedback, it would really help me to have a better overview of what I can do or not !

PS: don’t hesitate to ask me other details if needed

2

neoraptor:

  • First things first, is (raw)Lora suited for my (future) application ? Or is there better alternative ?

When you say raw I assume you mean not going through a cloud based gateway?

  • Is it possible to use Lora with a hidden/internal antenna (typically inside a case for the laptimer). I do not want to have an external antenna on the laptimer itself. The base could have antenna though.

How big is the laptimer case and what is it made of as these will affect the quality & range of the signal. If the box is big enough then you might be able to use an antenna mounted inside the box.

  • What range is doable with such hidden/internal antenna?

As above this depends on antenna size (box size) and box material.

  • Is it possible to make an antenna directly on the PCB?

Yes but good pcb antenna design is an art so better to stick with standard options if possible.

  • Which hardware is suggested for my application (on laptimer) ?

I have some nice LoRa32u4 modules that are basically an Arduino Leonardo & LoRa combined. I tend to use mine for low power applications but running all the time off battery should not be a problem.

  • Will a Raspberry Pi will work as a base station?

LoRa gateways to receive all the channels tend to be expensive but if you can stick to a single channel then they are cheap. If you have only one vehicle on the track then this would be fine as it will never trigger more than one speed trap at a time so all the traps can transmit on a single channel.

  • What update frequency could I reach with Lora? In the first prototype, I only need the data each 10 to 60sec, but is it possible to refresh the data more often (1-2 second for a GPS position for example) ? or is it already too much?

This depends on how much data is being sent and in what method. For LoRa to get long range it has to transmit more slowly. If you have a lot of data then update frequency my be affected. The laws in you country may also discuss the duty cycle of your transmissions so transmitting a lot may break the law.

  • Which frequency should I target ? 433Mhz or 863-870Mhz (I am in Europe)

I use 868MHz in the UK.

  • Power consumption is ok for use on battery?

Depends on what's connected and how big the battery is. My low power test device lasts 30 days on a 600mAh Li-po battery but it spends most of the time sleeping.

3

Thanks a lot Riva ! Your answer is really helpful !!

  1. Exactly, I plan to use it without gateway as they are too expensive for my (simple) use.

Is it possible to make a communication with 2 laptimers at the same time (same channel) and 1 base ?
I can make the difference between the 2 with an id for example, but will it be handle correctly on the communication (collision risks)?

  1. I plan to have a screen from 4-5", so case should be around 15cm x 7-10cm x 5cm (not defined yet).
    I will print it in PLA (plastic) for my first tests.

  2. I would like to reach 1km, is it doable with these conditions?

  3. Thanks for the input on PCB antenna. I will leave aside at first (or make some try with already made designs)

  4. I checked the regulations, and it looks like it should be ok if I use g3 sub-band or 433Mhz (where duty cycle is allowed up to 10%):

In Europe, duty cycles are regulated by section 7.2.3 of the ETSI EN300.220 standard. This standard defines the following sub-bands and their duty cycles:

g0 (863.0 – 868.0 MHz): 1%
g1 (868.0 – 868.6 MHz): 1%
g2 (868.7 – 869.2 MHz): 0.1%
g3 (869.4 – 869.65 MHz): 10%
g4 (869.7 – 870.0 MHz): 1%

  1. What are the performance differences between 868Mhz and 433Mhz?

  2. I will probably have the same use case for the power consumption, or even less: allways sleep until device is triggered (a few time per month maximum when on track)

  3. Is there a limitation if the node is moving ? My motorcycle can reach 100kph (pitbikes on karting track) and up to 300kph (1000cc bikes on real track). Can it be a problem for the transmission ?

Thanks again for the inputs :wink:

4

neoraptor:

Is it possible to make a communication with 2 laptimers at the same time (same channel) and 1 base ?
Yes but if both transmit at the same time then one or both transmissions will be lost. As this will be a point to point communications then you might be able to do receive acknowledge and if the transmitter does not get this ack signal then wait a random amount of time and try transmitting again.

I can make the difference between the 2 with an id for example, but will it be handle correctly on the communication (collision risks)?
A node ID will allow the RPi to determine what node the signal came from but won't help with signal collision.

  1. I would like to reach 1km, is it doable with these conditions?
    LoRa will easily do 1km line of sight with suitable antennas but depending on what's in the way (buildings/hills) may have problems. Also interference from bike electronics will affect the signal quality. Build a simple mock-up to test before investing lots of time and money into a finished product.

  2. I checked the regulations, and it looks like it should be ok if I use g3 sub-band or 433Mhz (where duty cycle is allowed up to 10%):

  3. What are the performance differences between 868Mhz and 433Mhz?
    Sorry, I don't know as I only have and used 868MHz modules.

  4. Is there a limitation if the node is moving ? My motorcycle can reach 100kph (pitbikes on karting track) and up to 300kph (1000cc bikes on real track). Can it be a problem for the transmission ?
    Electrical noise will affect the signal but placing the antenna away from engine and shielding the electronics will help. I don't think speed will be a problem. Are you sending lap data from a start line reader to the bike screen or sending data the other direction back to the pits?

Thanks again for the inputs :wink:

5

I think you are in danger of asking the forum to design the finished project before you have established the basics, i.e will you get the range you want, with the antennas you want to use and at a data rate that is adequate for the project.

I have probably done more range testing of LoRa than most, even picked it up from a satellite travelling at 17,000mph, but I cannnot speculate as to whether it will do what you want, the performance can vary by 1000:1 (or more) depending on the particular environment.

So as has already been suggested, you really need to do some tests ...............

6

@Riva: Thanks for the answer :wink:

  1. Yes, I can send an ACK to confirm reception of the package on another sub-band (it should be doable, now?). This is a good idea (and I can even send some payload with it (=very short indexed messages))

3-8. This is the plan. I know that I will have to go through (a lot) of tests, but at least I have a starting point for a base design.

@srnet: Your comment is welcome. This is a hobby project that I am doing with my brother, to use on racetrack with up to 5 friends with pitbikes on karting racetrack.
I intend in no way to make someone realize the project as it would spoil all the fun doing it myself !!

However, I asked so many question because I want to have a better understanding on how this radio transmission works (Lora). Objective is simply to start with a base design that is not completely wrong.
I have quite a lot of programming background, but not so much on radio transmission.

It is already clearer now (distinction between Lora/LoraWan distinction, knowing there are various configuration option, p2p use of Lora, ...) and I feel more ready to try my first prototype on the field (currently simple magnetic laptimer).

Just for information, I intend to make step by step prototypes to test eachtime new functionnality:

  1. Standalone magnetic laptimer: just to display the ideal/best/current lap and test the trigger mechanism with a reed contact (this point is now in progress, I just need to test a bit more on track, optimize power consumption, display layout, ...)

  2. Add Lora to prototype 1 + create the base station to transmit the laptimes each time a new sector is triggered:
    This will require lot of tests to have a good idea of how the communication is handle.
    Data transmitted will be only a few byte to begin with :

  • laptime coded on 16bits / with 10ms resolution, it should give me 655.35sec, which will be more than enough for the racetracks I go
  • maybe sector time as well (also on 16bits)
  1. If prototype 2 works well, try to add more laptimers and handle the transmission

Future: maybe add GPS + transmit the position from the node (but for this Lora may be too limited)

I started reading your blog and it is very impressive stuff, and it helps me to find some baseline and ideas to try.

srnet:
I have probably done more range testing of LoRa than most, even picked it up from a satellite travelling at 17,000mph, but I cannnot speculate as to whether it will do what you want, the performance can vary by 1000:1 (or more) depending on the particular environment.

Racetracks are normally quite open field, with typical max distance from the pits about 500-700m (hence the 1km range). Usually there are not many obstacles in between (not LOS though).

My data requirements are also not heavy:

  • for proto 2: 2 to 4 bytes received each 10-60 sec (depending on sector location)
  • for future: transmission of GPS coordinates a bit more often (5sec refresh rate?) But there is enough work to do before arriving at this step (and checking if it is possible or not)

Thanks again for the inputs :wink:

7

In principle LoRa ought to have the range, in general it has 10 - 30 times the range of other UHF type systems due in the main that it operates at up to 20dB below noise level.

My own LoRa tracker software puts out a binary GPS location packet, 11 bytes, lat, lon, alt and status. With only one transmitter 'on air' you can run the LoRa at a very low data rate for maximum range.

However if you have a few transmitters on the same channel\frequency you need to keep transmissions as short as possible to reduce the possibility of collisions, hence the reason for suggesting you will need to test for your situation, you want the highest data rate for the environment and antennas.

There is, unfortunately, no foolproof way with LoRa of detecting when another transmission is in progress. You can detect the packet preamble (at reduced sensitivity) from another station but not when the rest of the packet is in progress.

8

Thanks for the input srnet.
I will make various test then to find the sweet spot for the transmission (somewhere between slow transmission/long range and short transmission/shorter range).

Is it possible (and meaningfull) to implement some kind of dynamic band switching that could bring more performance? Depending of SNR or RSSI for example? Could the receiver can receive messages from various band at the same time?
Or is it possible to allocate a band when a new device connects ? (for example, connection with the band with the shorter range and allocation of new id + band at this moment?

At first, there will be only 1 device, then 2-3 devices on the "network", but I could already notice some problems.

What kind of refresh rate could I expect in ideal conditions (let say 400m LOS / 1device / 5 bytes) ? 1sec ? 10sec? If I read correctly, it will depend on the SF choose, right?

Thanks in advance !

9

You could implement band and\or spreading in an adaptive setup, this is done with the Things Network Code for instance.

There are 8 channel LoRa receivers, the SX1301, not inexpensive, and good luck writing the code to run it.

For time on-air download and install the 'LoRa Calculator'

I would concentrate on getting the bases testing done. You may be able to use very short packets (low spreading factor and high bandwidths) and whilst there may then be the risk of collisions you might be able to live with it.

10

Thanks for all these advices ! It is nice to have feedback from you.

I am still waiting for my 2 dev board which should still come this week (https://bsfrance.fr/lora-long-range/1368-LoRaM3-D-L151-LoRa-STM32-OLED-LiPo-development-board-long-range-ARM-SX1276.html). But in the meantime, I am reading a lot, that's why I may have some silly questions.

I found out that there is already the CAD (channel activity detection) feature implemented, which "is designed to detect a LoRa preamble on the radio channel with the best possible power efficiency" (citation from datasheet).
It looks like I could use it on the client while waiting for an answer or ack (or timeout before resending the packet).

I plan to make the dev in 2 phases:

  1. Working transmission between just 2 nodes, without any power optimisation + performance test depending on the communication parameters (bandwidth, SF factor, ...). Same channel frequency+parameter are used obviously.
  2. Transmission optimisation for 2 nodes (implement CAD instead of fully active transmission)
  3. Power optimisation for 2 nodes
  4. Add more nodes and test how it reacts:
  5. if needed (too many collision), add some frequency hopping mechanism in order to reduce the risk of collision. But this point will require more hardware on the base station (SX1301 or SX1308) and may not be required. Very interesting implementation here: Find Product Documentation

Is it possible to assign an address to each node or should it be part of the payload?

Do you recommend to use a library or write everything from scratch ?
I saw there are quite a few available:

Thanks !

Edit: some useful information about moving nodes: http://journals.sagepub.com/doi/full/10.1177/1550147717699412

11

CAD mode will only detect the pre-amble and it looses 6dB of sensitivity (IIRC) so you may not detect the weaker packets.

LoRa devices have no concept of an address, they just handle packets, so you need to implement your own addressing.

The LMIC library is aimed at The Thinks Network implementations and may not be sutiable for general purpose use.

I cannot comment on the other libraires, never used them. I wrote my own LoRa code, specifically for trackers and link testing, back in 2015, I had to really as the other libraries had not been thought of.

The comments in the article (based on calculations) about 'moving nodes' (land based vehicles) appear to suggest issues, to quote;

"Therefore, the LoRa technology might experience packet losses at relatively low velocities with these SFs. Lower SFs can tolerate higher speeds."

I have received LoRa packets at SF12 from a satellite travelling at 17,000mph, where the doppler shift is a great deal higher than from land based vehicle speeds, I guess I must have imagined it.

12

Hi Srnet,
I received my 2 dev boards yesterday and couldn't resit to make some "night programming session" :stuck_out_tongue:
But it was really productive: I ported my old laptimer code to the new chip (from AVR to STM32 L151) and integrated the OLED display + first simple implementation of LoRa (just send a string, which is really bad, but only for testing purpose).

And... around 4 in the morning, I receive my first "Hello LoRaWorld" message :smiley:
A few minutes later, I got my first laptimes transfered. I just tested it quickly in the house, moving from basement to last floor, without any problems, so next step will be to do some outside tests.

I used this library for the first tests (GitHub - sandeepmistry/arduino-LoRa: An Arduino library for sending and receiving data using LoRa radios.) which was really easy to implement.

So now, I have (again) some new questions:

  1. Concerning CAD, do you have some link concerning the sensitivity loss? I am a bit surprised that there is such loss. Is it because of the pre-amble overhead? But this is not present in all packet? Someone noticed that there was on the contrary too much false positive (http://semtech.force.com/lora/LC_Answers_Questions?id=90644000000Pm0nAAC).
    At the moment, I only have 1 base station and 1 laptimer, so I will have no problem on this side.

  2. I noticed already that there was no address concept on Lora. I will add 5 bits to have address (=31 address + 1 broadcast)

  3. On LoRa, I have to add the CRC myself for error detection + correction too if I am right?

  4. LMIC lib looks indeed far too big for my use.

  5. I will also have to add some SD logging system + GPS to make proper range and signal tests

  6. Regarding the speed problematic, the angular velocity from the satellite is a lot smaller than from a vehicle in movement, no ? This could greatly improve reception of "slow" packet (SF=12) in your case. I will have to do more test anyway to have a better understanding of the parameters and their influence.

  7. I noticed that LoRa has no duty cycle limits if transmission occurs below 5mW (page 11 from https://www.ofcom.org.uk/__data/assets/pdf_file/0025/38095/final_report.pdf). I will try to reduce the power in order to use this band (or if it is not succesful, I will use one of the band that allow 10% duty cycle).
    I found a paper yesterday on the influence of tx power over range (between 5mW and 25mW), but can't manage to find it again. Did you do some tests on this ?

  8. This is probably a basic hardware question: on my current dev board, I am using an OLED display on I2C + LoRa chip on SPI.
    However, I will use an epaper display in the next version which will also use SPI. If I want to use 2 devices on SPI, I need to "share" the access time of the bus between the 2, right? (Sorry, may be a silly question)

Overall, I am really pleased and impressed how the system works already. I need to start real-world testing now (on racetrack) and protocol the results.
But in the meantime I also look at various improvements (power optimisation, EEPROM saving of last/best/ideal laps, GPS+SD integration for a future version, RPM logging, wifi accesspoint on the base station, ...).

Thanks for your inputs again, it is helpful !

13

The posts are getting longer !

The angular velocity of a satellite is similar (as it moves overhead) to a car passing on a nearby motorway. The experient carried out in that report is flawed in any case, if you really want to test the effect, do it on a racetrack with a single vehicle, then you really can compare results between a moving and stationary vehicle in the exact same position, and with no possible effects from lots of other nearby moving vehicles.

On LoRa, I have to add the CRC myself for error detection + correction too if I am right?

LoRa devices will do that for you, as you will see if you study the datasheet.

Concerning CAD, do you have some link concerning the sensitivity loss? I am a bit surprised that there is such loss.

Cannot find it, but there is sensitivty loss in CAD detect, its not difficult to check for. CAD is a power saving way of monitoring the channel, so its to be expected that it would not have the sensitivity of a receiver running at full power. See the data sheet.

I found a paper yesterday on the influence of tx power over range (between 5mW and 25mW), but can't manage to find it again. Did you do some tests on this ?

The testing I have done indicate that LoRa follows the standard rules for all radio transmissions, to go twice the distance needs 4 times the power, to go 10 times the distance needs 100 times the power. It would be very strange if this were not the case.

If I want to use 2 devices on SPI, I need to "share" the access time of the bus between the 2, right? (Sorry, may be a silly question)

Odd question sure. The SPI is a bus, only one device can be accessed at time. There is no concept of 'sharing' the SPI, since the processor can also only run one bit of program at a time.

You do need to read the LoRa device datasheet cover to cover, there is lots of helpful information in there.

I really think you would be better to carry out some testing before you consider implications of possible problems that you may not even meet.

14

Hi Srnet,
Yes post are getting longer as I find it more and more interesting and challenging to discover so many new things ! I love it :stuck_out_tongue:

I will do track test to check how it reacts on moving nodes as it will be used there.

Thanks for the CRC tip. The check is now directly done by LoRa instead of adding it manually to the payload.
Works perfectly !

I will see if the CAD is indeed, not sure as I intend to send the data only each 20-60sec (depending on sector location). Once a sector is detected, I send the data from the laptimer and check if I get an ack back or not, and go to sleep after that, until next sector occur. So I may not need the CAD (maybe on the base station, but the power is not an issue there).

Ok for the transmission power, I will do some test about it then.

My question about the SPI is: if I have 1 display and the LoRa receiver on the same SPI, I can split the time to access the SPI without problem, right? or does the LoRa receiver requires a "full" SPI for itself?

I will take a full read of the datasheet to see if I am still missing a lot of things.
Do you have some link to understand how the RSSI and SNR should behave (which ranges are ok)?
Thanks again for your help !

Here are some photos from my project so far (yes, the display will be bigger in my next prototype :P):
Laptimer (on the bike):

1500×2000 341 KB

And base station (in the pit, with more informations about the laptimes):

1512×2016 377 KB

15

My question about the SPI is: if I have 1 display and the LoRa receiver on the same SPI, I can split the time to access the SPI without problem, right? or does the LoRa receiver requires a "full" SPI for itself?

The LoRa device behaves on the SPI bus like most all SPI devices do such that the bus is only in use when your program is reading or writing to the LoRa device.

As long as the chip selects are used correctly there should be no conflicts with multiple devices sharing the SPI bus.

Do you have some link to understand how the RSSI and SNR should behave (which ranges are ok)?
Thanks again for your help !

The RSSI is OK for strong signals, but for weak ones it does not work properly. Use the SNR as a much better indication.

I did post a note about this on my website;

http://www.loratracker.uk/?p=670