Sorry for the overly broad topic. I have been studying LoRa transmissions at the physical layer and I have several questions. IDK if this is the best forum, but I don't know of a better place to ask.
Ultimately it is my goal to communicate with a large bunch of nodes to transmit small pieces of data. I (think I) have no need of higher protocols such as LoraWAN and am really just interest in LoRa physical at the moment. The project could talk to 1,000 nodes total in groups of devices of up to 8 per group. The amount of data transmitted would be no more than four bytes to the nodes with a confirmation response from the nodes. Transmission distance at the groups would be no more than 300 yards. Environment would not be noisy as it would be outside of population centers. I require the command to execute at the receiving device in under 100ms (shorter would be preferred). The response could take several seconds.
Assuming SF=8 for convenience of 1 byte per chirp and 500,000 hz broadband for speed, It seems to me that I am bought into 8 upchirps (preamble?) followed by 2.25 downchirps (sync), followed by 4 chirps of data plus 1 to 4 more chirps for the coding ratio. It appears to me that I have a lot of overhead in the upchirps relative to the data size and I am loosing 4 ms just doing upchirps and more than 50% of the communication in just creating the packet. This may be acceptable to the project, but I cannot find good resources on the requirements of the preamble and sync. I cannot figure out if the LoRa packet includes a packet length definition, which I think is a "header".
Regarding addressing, several transmitters could simultaneously communicate with all devices at a time, but only 1 transmitter would communicate with groups of up to 8 devices. My intention is to designate Group 1 to 902.0-902.5 MHz, Group 2 to 902.5 - 903.0 MHZ, etc. in order to avoid a noisy environment on one frequency and I would use 500 KHZ bandwidth to minimize transmission time. Is it acceptable to have one frequency butt up next to another frequency in order to address different groups? Could they overlap some if I need more than 52 groups while maintaining 500 khz bandwidth? I am in the US. Is there an alternative strategy to the addressing problem that does not compromise on transmission speeds? I looked up code words for LoRa, but that sounds like an advanced topic. I would like to minimize addressing inside the data packet as this would increase the chance for collisions or noise between transmitters among the 1,000 receivers.
Periodically I would like the ability to perform a roll call of all devices and collect status information (e.g. battery voltages at receivers). Slower transmission times are acceptable but not at the expense of the transmitters communicating to the "groups" discussed in #2. This transmission could be over a mile from a stationary transmitter and therefore it would be beneficial to lower the bandwidth and up the spreading factor. My reading appears that this could be supported with orthogonal communications by using two different spreading frequencies. Maybe I am asking too much here, but any good examples of this being utilized in the arduino environment?
I am a bit into LORA so I think what you want to do is possible but it will be a steep hill and will take a few months.
I didn't really see a question other than are there examples. My response to that is to look at the examples provided with the various libraries.
I didn't really see a question other than are there examples. My response to that is to look at the examples provided with the various libraries.
Summary Questions:
Is there more to a packet than preamble, sync, data? Is there a data length portion of the header or is this something higher than the "physical layer"? Can the non data be shortened without compromising the communications?
Is addressing by frequency band acceptable with adjacent bandwidths? Can you overlap the bandwidths or is this a bad idea? Should I consider alternative forms of addressing?
Is orthogonal communications possible with 1 demodulator?
There are two types of packet Explicit and Implicit.
Explicit packets contain a header which contains the payload length, the FEC rate in use and a flag for the presence of a packet CRC.
Implicit packets are fixed length, no header and the receiver must know what length to expect. Implicit packets can shorten transmit times (slightly).
Further details of the above are in the LoRa device datasheets.
Not aware that Semtech provide any details on 'customising' the headers and packet formats.
You can reduce the preamble length from the normal setting of 8 but to find out what impact that has on packet reception reliability you would have to carry out tests in your environment.
LoRa devices do not have super selective RF input stages so a transmission on a close by frequency will affect the operation of the receiver on its base frequency, particularly if the close by frequency transmission is strong.
Maybe you should do some experiments, easy enough ......
They are not.
Duty cycle restrictions apply to all transmissions from the device.
So I think this matches what you are saying: explicit vs. implicit. That website says "the radio transmitter will add another 4.25 symbols resulting in a final preamble length of 8 + 4.25 = 12.25 symbols." I think a preamble setting of 8 means that there are 8 up chirps and 2.25 down chirps. Where are the other 2 symbols coming from and what is their purpose?
I think that the best strategy may be to approach a "group" of 8 devices on a lower bandwidth and higher spreading factor (explicit mode) that would support the long distance "roll call" requirements. I could then jump into implicit mode by "logging in" to the groups that would set the TX and RXs to SF=6 and BW=500000, gain the benefit of a higher symbol rate, accept the short distance communication, perhaps drop preamble. Then I would need to figure out a way to either log out or time out the RXs that would reset them back to explicit mode long range. Log out could be an implicit data receipt of a number not designated such as 000000 or 111111. What do you think?
Right now I am just experimenting with distance testing to get a feel for range and transmission length. I have a pair of heltec lora 32V3's. I have some makerfabs lora relay boards that that may be a good project to do this Spreading Factor changing that I discuss in my response #14. I am not the best coder, but I would like to understand the theoretical limits of the technology before investing too much time if it doesn't make sense.
Not sure how knowing the reasons Semtech made the preamble that way is significant, as far as is known you cannot change those numbers ...............
Semtech used to have a developers forum where that sort of question could be asked, but thats now closed, so presumably you need to contact them direct.
There are a few things that Semtech have not fully explained about LoRa, but that's their prerogative, no-one else makes the devices.
I'd be glad to. I foresee a commercial application, but the project I have in mind would be for personal use. Perform a google search on "sporting clays" if you are not familiar with the sport. Stations are typically (2) separate disk throwing machines that are launched together ("true pair"), a delayed pair, or a single followed by another single when the first shot is taken ("report pair"). Some stations could be a single machine (e.g. "Trap"). Other disciplines could be up to 8 machines ("5 stand"). Some machines could have up to 3 different axes of movement (e.g. side to side, up down, tilt). So far I have referred to the stations as "groups" in this discussion.
The leading manufacturer in the space is promatic. They are incredibly expensive (~$900 US / machine controller). They also do not have great single user controls nor great motor controllers. Usually a buddy presses a button to launch a target for the shooter (non trap). The trap discipline relies on a bulky microphone to trigger the machine to launch. I would like to approach a group of machines individually by selecting the "group" and then program in the target order and call "pull" to launch the targets. The time from saying "pull" to launch needs to be short, hence the 100 ms requirement. 1 chirp would be plenty of data to tell the machines to launch a target. Machines are typically well within 100 yards, but some machines could be positioned beyond that as long as the target gets to within about 50 yards of the shooter on its trajectory. Then there would be several seconds of recovery time for each machine prior to shooting another pair. After you leave the "group", updated data could be sent back to the clubhouse (e.g. battery capacity, solar charge rate, estimated targets left in machine.) Another set of shooters may come in or the "group" could sit idle for minutes to hours.
I like the distance capabilities of Lora to keep an eye on machines that need to be topped off with targets or have an issue with the (deep cycle) battery that powers the machine but the individual shooting does not need long distance messages when they are calling for targets. Hence why I like your guidance on implicit vs explicit. If possible, I think an explicit command to a "group" directing the RXs to a lower SF and higher BW and implicit header mode would meet the requirements of the shooter and would prevent excessive signal noise with other groups on a different band.
This would be something on a farm and therefore not likely to have lots of background (signal) noise other than what other groups generate.
If it were my project, I would not be that that interested in the minute detail of each and every chirp and what it does. The standard LoRa parameters are known to be reliable and efficient.
At SF8 BW with a payload of maybe 6 bytes you might just be able to build a secure packet that could address 1000+ nodes with reasonable assurance that a rogue packet or a phantom will not cause a false trigger. Such a packet would have an air time of 14.46mS. If you reduced the preamble, away from the accepted norm, you might reduce packet length by 1mS or so. A small improvement with a unknown impact on errors.
Then of course there is the issue of reliability. RF packets are never 100% reliable, so for the application one might assume that the controller needs to keep sending the control packet until it receives an acknowledge (that it knows is valid) from the receiver. This can slow things down quite a bit.
I presume this is the same project as this previous topic;
Yes to the same project. I haven't done an arduino project in several years; I am a bit rusty. I don't know why I am that interested in this project; I could use a garage door opener to do what I need to do.
Regarding confirmation of launching a target, I think a low failure rate is acceptable and you just reshoot the pair. I think it would be better for the user to resend the command with another "pull" than to send a 500 ms late target. Most of the time it is a broken clay in the machine, but I have had several issues with corded buttons. I would say probably 2% failure rate of the machine. I also have probably 4% or 12% failure of the microphone to trigger during trap. The sport accounts for some failure rate.
Here is another question. If i keep the CRC or increase it to something like 4/8, does the demodulating RX correct missing (or incorrect) data or does it flag the message as invalid? I feel like direct line of sight with low noise (one TX at a time on a groups SF and BW) at 150 yards or less would have a very high successful packet rate.
LoRa does do forward error correction (FEC) on packets and the standard coding rate is 4:5. You can increase the coding rate to 4:8 which can correct for more errors at the expense of greater air time packets.
The CRC, if used, is appended to the end of a transmitted packet and is used by the receiver to ensure that the packet data is not corrupt in some way.
However the CRC check does nothing to ensure that the received packet is one that was sent by your specific transmitter. A received packet can pass CRC but be a rogue from another foreign transmitter or disruptor or a phantom.