# Can timing information be used to compress data for LoRa transmission?

I have a course challenge. It involves calculating an FFT of an audio signal of 2 combined frequencies (up to 20KHz) then sending it over LoRa through to a fixed receiver. There will be an interferer. Spreading factor is fixed. Grading is based on power consumed by the transmitter and time between start of calculation and receiving an acknowledgement from the receiver. The exact degree of each grading is not unknown.

We may modify any parameters, such as antenna, baud / bitrate, etc, FFT calculation, compression.

I have a strategy for compressing the values in single bits. Is this possible:

The receiver will receive a bit to start counting, and at that point, it will start counting on its internal clock. Once the transmitters internal clock = x * 100 nanoseconds, where x refers to the value being sent and 100 nanoseconds is the likely accuracy of a GPS signal, it will send a 1 bit. The receiver, having felt x * 100 nanoseconds delay, will decode this message as having the value x.

The benefit will be sending 1 bit vs 16 bits of information will use less power on the radio module, but the waiting could be a penalty for time and static / dynamic waste due to leakage + counting nanoseconds on the accumulator.

I recognize LoRa had a minimum required packet size, but given a required spreading factor of 7 and likely redundancy to deal with an interferer, is this a worthwhile scheme?

Note: The transmitter and receiver are two copies of the same hardware microcontroller.

• wait, is one of the constraints of the challenge "you must use LoRa"? Otherwise, you'll certainly not win based on speed over a mere 10m... or even power. LoRa's use case is a completely different one, and the power you'll need to transmit one bit is far more than you'd need to send 20 bits using something that uses the fact that the receiver is but 10m away. Oct 6 '18 at 8:49
• Also, compared to short range transmissions, keeping two GPS receivers running uses a lot of power (compare how long your phone can run logged into the network, where it regularly has to send data, with GPS on and off: GPS is really pretty power hungry). Oct 6 '18 at 8:52
• Generally, the method you're describing has a name: it's pulse-position modulation. And you really don't need GPS for that, anyway. But it's not a data compression; on the contrary, it's energy-wise a suboptimal choice. I could write a rather lengthy answer, but I'd need to know a lot more about the actual challenge you're facing, including all constraints. Oct 6 '18 at 8:54
• (oh, and while it's possible to make a LoRa transmitter transmit at a specific point in time, you'll have a pretty hard time evaluating that time with just a LoRa receiver attached to a microcontroller! How would the microcontroller know the exact time the reception happened? It typically only gets data bits from the LoRa module, over a link that is far slower than your 1/100 ns = 10 MHz!) Oct 6 '18 at 8:56
• So, there's just too many things that just don't add up in your question; I'm afraid I can't answer without you giving much more background on the whole issue, sorry. Oct 6 '18 at 8:56