Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Frequency choice #4

Open
valentinb opened this issue Oct 13, 2017 · 10 comments
Open

Frequency choice #4

valentinb opened this issue Oct 13, 2017 · 10 comments

Comments

@valentinb
Copy link

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

@yohanboniface
Copy link
Contributor

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
Copy link

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
Copy link

yes perfect, use of the 2 freq

@pjalocha
Copy link

pjalocha commented Oct 16, 2017

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
Copy link

acasadoalonso commented Oct 16, 2017 via email

@optimaltracking
Copy link

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
Copy link

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
Copy link

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
Copy link

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
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants