459MHz UHF legal Tx and Rx - Arduino based programability.

[thundead]

I've attached a excel spreadsheet with some freq calc. will update my fw accordingly.

Cheers
Mihai.

[Coyote]

Ive just modified my post Mihai, i had "char hop_list[3] = {10,15,25,35,45};" but it should be "char hop_list[5] = {10,15,25,35,45};" for 5 channels i believe ?

[thundead]

that is correct :) but your last channel needs to be 45 not 50 if you want to stay legal :)

Ive just modified my post Mihai, i had "char hop_list[3] = {10,15,25,35,50};" but it should be "char hop_list[5] = {10,15,25,35,50};£ for 5 channels i believe ?

[Coyote]

kk got it cheers, ill modify posts

Ah i noticed my channels were at 45, only the channel list was 50, must have had a blonde moment :)

[Devonian]

Yep, sounds good (the highest frequency should be 495.475 to allow for the bandwidth of the carrier not to overstep the 459.500 upperlimit).

e.g. (I've corrected a couple of typo's)

//Frequency = CARRIER_FREQUENCY + (StepSize(10khz) * Channel_Number)
static unsigned char hop_list[3] = {10,15,25,35,45};

459.0 + (10kHz x 10 (= 100kHz)) (1st channel hop from your defined base frequency of 459) = 459.100
459.0 + (10kHz x 15 (= 150kHz)) (2nd channel hop from your defined base frequency of 459) = 459.150
459.0 + (10kHz x 25 (= 250kHz)) (3rd channel hop from your defined base frequency of 459) = 459.250
459.0 + (10kHz x 35 (= 350kHz)) (4th channel hop from your defined base frequency of 459) = 459.350
459.0 + (10kHz x 45 (= 450kHz)) (5th channel hop from your defined base frequency of 459) = 459.450


By using 10kHz StepSize, all you have to do is add a zero after the hopping channel number.

Nigel.

[Coyote]

Thanks Nigel, shouldnt char hop_list[3] be char hop_list[5] though ?

[thundead]

yes it should :)

Thanks Nigel, shouldnt char hop_list[3] be char hop_list[5] though ?

[Coyote]

thundeadMod 3.3 on its way :)

Cool, it moving on pretty well in just 1 week :)

[Coyote]

Am i correct in thinking then, you could have two users, using the same channels in their hop, but still fly fine together as long as their headers were different ?

[papa_lazerous]

Am i correct in thinking then, you could have two users, using the same channels in their hop, but still fly fine together as long as their headers were different ?

That's the theory, how robust it would be is a matter of testing though I think. It would be good to get 2 OpenLRS users side by side to see how well it all performs.  I would think with the headers being different your Rx will reject packets from the 'other' Tx but I if both are transmitting on exactly the same frequency at exactly the same time I think you will still see some issues.  The reality is if you hop over 6 channels they will never be in sync so both Tx's will be transmitting not only with different headers but also on a different channel at any given time.

[Coyote]

Yeah i think it wouldnt be as effective as hoped, which brings me to another potential idea for your firmware Thundead. An option in the program to choose a predefined set of channels.

I.e. If I were to flash mine and PK flashed with the same tool, we would be hopping on the same channels, but if an option of say channel sets for exampe A,B,C or D meant we could flash with different channel sets and know our channels wouldnt clash at all throughout the hops ?

So for example, one set 10,15,25,35,45, another set 12,17,27,37,47 etc etc

Then there would be seperation of sorts coupled with different headers would make it more effective

[papa_lazerous]

This is something you could implement yourself very easily if you see this section of code in the config.h for the Tx this is the hopping channels used, ofcourse the Rx's config.h would need altering too.

//###### HOPPING CHANNELS #######
#define CHNO 6
static unsigned char hop_list[10] = {0,45,5,40,10,35,15,30,20,25};

[Coyote]

Yeah easily enough done, but i thought it could be a cool feature to add to Thundeads uploading software. Then you could just tick a checkbox, the checkbox defines a set, the sets are predifined in sketch and defines your choice in its rendering

[papa_lazerous]

Agreed, tbh I would like to see some other cool stuff implemented first.  I wonder how much we can ask for before Mihai gets fed up (only joking mate)

I must say though that the OpenLRS configurator at the moment is exactly where OpenLRS should have been from the start, its great that Thundead/Mihai has done this but a crying shame that Melih at Flytron let this product out in the wild with very little backup, sure its open source but it pays to make it open to more people to sell more units.  Something that Thundead has done :)

[Coyote]

Agreed, tbh I would like to see some other cool stuff implemented first.  I wonder how much we can ask for before Mihai gets fed up (only joking mate)

I must say though that the OpenLRS configurator at the moment is exactly where OpenLRS should have been from the start, its great that Thundead/Mihai has done this but a crying shame that Melih at Flytron let this product out in the wild with very little backup, sure its open source but it pays to make it open to more people to sell more units.  Something that Thundead has done :)

Agreed too, thanks to Mihai for the work, and of course Nigel too :)

On the features though, im a great believe in keeping the features simple for now, then the system just works reliably. RSSI and telemetry is kinda cool though