UAVTracking / UAVTrackingProtocol

An open radio protocol for transmitting UAV flight data in real time.
https://xkcd.com/927/
11 stars 4 forks source link

Frequency choice #4

Open valentinb opened 6 years ago

valentinb commented 6 years ago

Why has 868.4Mhz been chosen ? It would be interesting to justify it.

yohanboniface commented 6 years ago

Not directly answering the (good) question, but adding some thoughts on the topic from Paweł from another communication canal:

We only talk Europe for now thus we want to use same band as FLARM and OGN: 868.0-868.6MHz. For diversity both frequencies should be used, they could even be used at same time time, thus at given time slot one drone could transmit on 868.2 and the other on 868.4MHz. This (almost) doubles the capacity of the system as a ground-base SDR receiver can hear them both however a third drone would only pick up one of these, however this may not be a primary issue here.

pjalocha commented 6 years ago

I understand one of the goals of this protocol is to be compatible with th eold chip nRF905 which is used by Flarm units. This chipos can only do multiples of 0.2MHz as the center frequency thus for the 868.0-868.6MHz band we can only have two channels: 868.2 and 868.4MHz.

I suggest to use both channels. In some areas local interference can blind one or both... but by using both you always get more chances.

Flarm and OGN tracker actually send the position twice on the two frequencies. This doubles the reception chances and on the reciever side allows to combine both signals for increased SNR and improved range.

For the new protocol it appears we would have a bit longer packets thus according to the 1% rule we would not be allowed to transmit two packets every time. But still the frequency could be adjust based on the situation and some signals could still be sent on both frequencies.

optimaltracking commented 6 years ago

yes perfect, use of the 2 freq

pjalocha commented 6 years ago

One should say something about the transmission timing and the actual choice of frequency. We could go for complete random choice of both frequency and time so that distributions are completely flat - some modification to the OGN receiver would be needed.

For FLARM/OGN the transmission happens actually in slots and the OGN receiver senses both frequencies in parallel but timewise it is sensitive only from 0.35sec from the GPS PPS to 1.25ms after the next PPS. Flarm transmits from 0.4sec to 0.8sec after PPS on one frequency and then between 0.4sec and 1.2sec on the other.

One could define certain short perdios of time for frequency switching and radio setup. For now the time 0.2-0.4sec after PPS is free from transmissions.

Transmission could as well start at any time or we could define distinct moments like on multiples of a given period. It is not clear to me which is better to minimize collisions. Transmitting on a time-grid could pass some additional information.

acasadoalonso commented 6 years ago

Pawel et al:

Are taking in consideration the different frequency sets that is used in the Americas and Australia. Over there they use the ISM band of the 915 Mhz. In addition to that in the case of the Flarm they use frequency hopping.

AC/.

On Mon, Oct 16, 2017 at 1:59 PM, pjalocha notifications@github.com wrote:

One should say something about the transmission timing and the actual choice of frequency. We could go for complete random choice of both frequency and time so that distributions are completely flat - some modification to the OGN receiver would be needed.

For FLARM/OGN the transmission happens actually in slots and the OGN receiver is senses both frequencies in parallel but timewise it is sensitive only from 0.35sec from the GPS PPS to 1.25ms after the next PPS. Flarm transmits from 0.4sec to 0.8sec after PPS on one frequency and then between 0.4sec and 1.2sec on the other.

One could define certain short perdios of time for frequency switching and radio setup. For now the time 0.2-0.4sec after PPS is free from transmissions.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/UAVTracking/UAVTrackingProtocol/issues/4#issuecomment-336865347, or mute the thread https://github.com/notifications/unsubscribe-auth/AHw8Z9i54f8KV5-KLzFkQwhZ-Hps6D-Aks5ss0UtgaJpZM4P4u5f .

-- Angel Casado

optimaltracking commented 6 years ago

Be carefull to one fact: The goal is to be able to receive the signal with a cheap hardware. It means on a fixed frequency. If you want to make a "detect and avoid" system, you can not scan all frequencies. And the goal is to create a market for ground station. SO we have to think to "cheap receivers"

acasadoalonso commented 6 years ago

We are building cheap receivers like the OGN tracker for about €30, that handles the frequencies for Europe and the Americas ... the trick is to detect the frecuency area based on the GPS position and based on that use the proper frequencies

pjalocha commented 6 years ago

The frequency hopping needs just to be agreed on the frequency range and sequence of channels so ordinary hardware can handle this. We can thus easily extend the specification. For frequency hopping it would be good to have a short period of time for switching frequencies thus we can have the one we already have: 0.2-0.4sec after PPS.

optimaltracking commented 6 years ago

Well the target is 10 Euros for a transmitter. For this reason we need extremly simple hardware. Frequency hopping or GPS based time slot is complex and should be avoided.

pjalocha commented 6 years ago

Why is GPS based time slot too complex ? You don't even need PPS... just the time when the GPS gives you the data is good enough. Frequency hopping is just switching to a new frequency... you need to do it anyway, if you want to use more than one frequency. No aditional hardware is required for both of these features.