Well I'm interested (and curious), send me a PM.

A point to remember is that when comparing distances to FlipFlaps tests he was using a real vertical antenna with radials, on top of his metal car which adds to the ground plane, for the first tests and a high gain yagi for the longer range tests. Using a dipole or a monopole with out a ground plane is just not going to yield similar results.

It would be really usefull to do some tests with the same gear in the same place with different antenna to quantify the differences.

Cheers

Originally Posted by mike_kelly

A point to remember is that when comparing distances to FlipFlaps tests he was using a real vertical antenna with radials, on top of his metal car which adds to the ground plane, for the first tests and a high gain yagi for the longer range tests. Using a dipole or a monopole with out a ground plane is just not going to yield similar results.

It would be really usefull to do some tests with the same gear in the same place with different antenna to quantify the differences.

Cheers

Mike I was getting 30ft of range. Were not talking about similar results here. Were talking about usable results.

It appears that OpenLRSng has gone through some updates since I last looked into it. Its now possible to program TX's as RX's, exactly whats being done with flipflaps firmware. They also are supporting 16 channels. It seems that in addition to programming 1w TX's as RX's there are some new 1w RX's on the market as well. I think i'm going to see if OpenLRSng helps with any of the issues i've been having. Will report back.

Originally Posted by JonnyJ

It appears that OpenLRSng has gone through some updates since I last looked into it. Its now possible to program TX's as RX's, exactly whats being done with flipflaps firmware. They also are supporting 16 channels. It seems that in addition to programming 1w TX's as RX's there are some new 1w RX's on the market as well. I think i'm going to see if OpenLRSng helps with any of the issues i've been having. Will report back.

All true but I think the Mavlink telemetry might be a problem. Let us know how it goes.

Originally Posted by mike_kelly

All true but I think the Mavlink telemetry might be a problem. Let us know how it goes.

Yup youre right. As per Kha

Originally Posted by kha

Sadly the mavlink patches are not yet in, there is quite clean patchset atm. but havent got time to integrate.

So after doing some playing and researching on the latest OpenLRSng status I'm curious. Flipflap why did you choose to go down a completely different road with your firmware than just adding functionality to the NG fork of OpenLRS? Was it necessary for your needs to ditch the customizability offered by OpenLRSng, such as specifying your frequency hopping channels, 16ch ppm support, etc?

The functionality offered by the OpenLRSng Configurator looks great. At my current moment i'm really digging the spectrum analyzer they have built in. But in my playing I have still not been able to bind a 1w TX programmed as RX. So Flipflaps firmware certainly wins in ease of use. But in trying to diagnose my current range issues its interesting to see the differences between the firmware forks and im curious why you choose the route you did.

It's a good question, and to answer you've got to get back more than one year in the past, when I published this firmware :

Openlrsng had numerous issues especially with reliability (the flash memory corrupted sometimes for no reason, and there were regular bugs due to quick addition of features), with APM support, which is still the case, and with lack of support for 1W TX as RX.

On my side, I was already playing with openlrs well before openlrsng started, and had already made many modifications to have a reliable and working APM telemetry, and 1W TX as RX.

There was no real reason to change everything, but as this could be useful for other users, even with less additional features than openlrsng, I published it as is.

Now, why not simply branch openlrsng is a good question, but in short the logic is different, it would require so many changes that it would be difficult to maintain a separate branch while easily incorporate changes made on the main branch.

Notice I discussed this topic with kha in the openlrsng thread early 2014, https://www.rcgroups.com/forums/show...4#post27453634

It's fine if openlrsng finally allows to use a 1W TX as RX, but it will only be really useful when the telemetry issues will be solved.

Originally Posted by flipflap

It's a good question, and to answer you've got to get back more than one year in the past, when I published this firmware :

Openlrsng had numerous issues especially with reliability (the flash memory corrupted sometimes for no reason, and there were regular bugs due to quick addition of features), with APM support, which is still the case, and with lack of support for 1W TX as RX.

On my side, I was already playing with openlrs well before openlrsng started, and had already made many modifications to have a reliable and working APM telemetry, and 1W TX as RX.

There was no real reason to change everything, but as this could be useful for other users, even with less additional features than openlrsng, I published it as is.

Now, why not simply branch openlrsng is a good question, but in short the logic is different, it would require so many changes that it would be difficult to maintain a separate branch while easily incorporate changes made on the main branch.

It's fine if openlrsng finally allows to use a 1W TX as RX, but it will only be really useful when the telemetry issues will be solved.

That all sounds reasonable to me. I was just curious. It seems that the NG branch has come a long ways. But for some reason they must be resistant to adding mavlink support since many have requested it but its still not in. You would be more knowledgable about the reason for that than myself. I assume it is because it simply doesn't work with the code as they have written it or its just a heap of work to implement with their current code.

I'm playing around with getting their 1w bidirectional link working just so I have that knowledge should they get telemetry implemented in the future. But I agree with you, until they have mavlink telemetry working its really not that useful to me. Hopefully simply moving to a the DTF module will resolve my issues and I will be able to continue using your firmware. Time will tell!

Well they focus on keeping a low RF rate to have a longer range, but at some point it's a trade off between max distance and baudrate.

I've chosen to have a shorter range (12 km), but 100% APM telemetry. (And used for this some secret stuff of course.)
At that time the RF rate was 125 kbps, and now I lowered it to 57 kbps, and the module was powered at 3.3V so it should be possible to go much farther. Also the limit was the plane battery, but I don't want to claim a distance that I didn't try in practice.

Some have branched the openlrsng (gitsly), and made a different choice, by ditching some APM packets to save bandwidth while keeping a low RF baudrate.

All different approaches have advantages for some usages, I really wanted to focus ULRS on usage with APM or other telemetry-based systems, and ensure a high reliability as nobody wants to loose an APM-equiped plane 10 km away.

Regarding the number of channels, the Pololu version is almost ready, and adds 24 channels to the normal 8, for a total of 32 channels.

Originally Posted by flipflap

Well they focus on keeping a low RF rate to have a longer range, but at some point it's a trade off between max distance and baudrate.

I've chosen to have a shorter range (12 km), but 100% APM telemetry. (And used for this some secret stuff of course.)
At that time the RF rate was 125 kbps, and now I lowered it to 57 kbps, and the module was powered at 3.3V so it should be possible to go much farther. Also the limit was the plane battery, but I don't want to claim a distance that I didn't try in practice.

Some have branched the openlrsng (gitsly), and made a different choice, by ditching some APM packets to save bandwidth while keeping a low RF baudrate.

All different approaches have advantages for some usages, I really wanted to focus ULRS on usage with APM or other telemetry-based systems, and ensure a high reliability as nobody wants to loose an APM-equiped plane 10 km away.

Regarding the number of channels, the Pololu version is almost ready, and adds 24 channels to the normal 8, for a total of 32 channels.

FlipFlap,
I am wondering what you are using the Pololu for? Are you multiplexing the extra channels into a 8 channel ppm stream?

2 questions......

1. MultiWii compatible? Tested?

2. ETA on more then 8 channels with this hardware?

Well crap. I guess I just ordered hardware that won't work with flipflaps firmware. I was hoping that all the hardware was essentially the same and if it worked on one it would work on another openlrs hardware project. I guess thats not correct.

Originally Posted by kha

The firmware for OrangeRX won't work on dtf as dtf yses improved schematics. It is rather easy to make firmware for either like olrsng does.

Any idea how hard it would be to support DTF UHF as well as flytron and Orange? Bah all this coulda been avoided if only flytron made a JR module.

Originally Posted by mike_kelly

FlipFlap,
I am wondering what you are using the Pololu for? Are you multiplexing the extra channels into a 8 channel ppm stream?

No, the Pololu is directly connected to the ULRS too :

Originally Posted by flipflap

No, the Pololu is directly connected to the ULRS too :

Interesting so you are leaving the standard controller stream alone. No reduction of the sync pulse width. Then running another stream for accessories? How do you mix the two? Do you use a different kind of modulation for the new stream?