next topic »

[Reply #135 on:]

Thanks.
In the mean time went back to some code you had shared before and changed it to include downlink telemetry. (I really didn't like openLRS code)
But I'll use the one you shared now that is better tested than mine.

One question, on your old code that you shared I was getting servo glitches at a regular interval, any idea what was it (I suppose it was the RF22 irq messing the servo library?
I didn't spent much time as I need to generate instead a PPM signal (for the Multicopters FC's) but I was curious about it
seems like the

One other thing, do you get a stable RSSI reading? I'm getting something like 104, 80, 70, 90, 60,... ended up adding a moving avg filter to help. I was expect some fluctuation but not so big as this.

[Reply #136 on:]

Hmm... are you using my modified version of the RF22 lib? Because I thought I solved that particular problem, my servos seem fine. Try the new code, and see what you get. I will investigate a bit more. I guess I could think about adding PPM out, but because I implemented autopilot directly on the receiver, I never had the need... It might be simpler to have the receiver talk to multicopter FC directly over serial port instead of the convoluted digital->PPM->digital thing.

Also, my new telemetry code is not fully tested!! Make sure you don't put it on something expensive! And because the rx defaults to transmit telemetry data at full power, make sure you have an antenna on the receiver all the time!

My RSSI values are very stable, down to the last digit. The trick is the read RSSI right after receiving a packet, otherwise it will be wrong.

[Reply #137 on:]

I started using your new code and the issue was fixed. But I was curious about was causing it in the older version.

I already implemented PPM but it makes the RF22 stop working.
I've set the timer1 to do the work, similar to what the Servo library does, so shouldn't be any issue...

If there is interest maybe host this somewhere, google code or github.

[Reply #138 on:]

The key to good interrupt handling is to make sure the code in the interrupt handler is as small as possible. IIRC the original RF22 lib had all kinds of stuff in their interrupt handler function, including reading data from the module, which meant everything else (like servos) had to stop when it receives a packet. When this coincides with a servo pulse, you have a glitch. I move the data reading outside so the actual interrupt takes almost no time.


Does you PPM code work on its own? Debugging these interrupt and timer issues are quite difficult! If you share your code I will have a look at it sometime this week. Can't promise anything though...

[Reply #139 on:]

Thanks, I noticed that you're not using the latest version of RF22 so I wanted to check the changes to port it to the latest version.

My PPM code it running fine on it's own, I set some static values and the signal generated is clean. I matched the time intervals to what FrSky receivers do. (I'll post some screenshots later)
Is still not optimal as I lock it during the signal generation, but I saw a good example on how to release the control between the intervals of the pulse shifts. As soon as I made the current model work I'll try the better one.

I'll create a Google code page later and share it there.

[Reply #140 on:]

Here it is: http://code.google.com/p/zlrs/

That version the PPM sum runs fine on pin D8, perfect 18ms like FrSky but no RF22...

This is the output from a FrSky D4FR


And this is from the code of the LRS


The channels interval is showing the ~1500ms the default value I've set because it can't get data from the RF22.

[Reply #141 on:]

Hmm... are you using my modified version of the RF22 lib? Because I thought I solved that particular problem, my servos seem fine. Try the new code, and see what you get.

Hello zitron.  Can you summarize what modifications you have made to your RF22 lib?  What problems did you need to fix?

Best Regards,
George

[Reply #142 on:]

Code:

Here it is: http://code.google.com/p/zlrs/

Sorry I don't know how to use google code, where is your code?

Hello zitron.  Can you summarize what modifications you have made to your RF22 lib?  What problems did you need to fix?

I am really bad at documenting stuff, I think I basically moved the read data stuff from the interrupt handler to only run when you call the receive function.

[Reply #143 on:]

There you go: http://code.google.com/p/zlrs/source/browse/#git%2Frf22_RCrxHWS_tele

I prefer GitHub but I decided to give a try to Google Code GIT hosting.


Got some time today to look into this, seems the way I've set it is consuming too much time not allowing the RF22 to process data.
I've changed the timer to only trigger and even on the pulse shift and the RF22 started to work. Now I need to correct the PPM output as it's not been generated correctly.

[Reply #144 on:]

...and it's fixed!
Took some ideas from openLRS code and ended up only using Timer1 as overflow interrupt.
I'll be submitting the updated code soon and start adding a failsafe feature.


Update1: Code submitted and video made of the test  


Update2: FrSky telemetry support added. RSSI+Voltage levels working on a modded 9x radio.

[Reply #145 on:]

Wow awesome! I like the changes.

Which version of the 9x firmware do I need?

I'm thinking about building a tricopter, I might just copy your setup!

[Reply #146 on:]

I'm using the er9x, but I think open9x will work as well they use the same mods for telemetry.

In multicopters and for FPV I just love the tricopter, the super responsive tail makes it really fun to fly.
If you need any details just let me know.

I'm trying to determine with platform will be the one making the first test running the LRS.

[Reply #147 on:]

Just a video showing the maiden flight.
Next step is to make some proper antennas, you can hear the drop packets beeps (as well as me speaking loud).

[Reply #148 on:]

Nice! Were you flying on 1mW? 1mW Should be good for 100m with normal antennas.

[Reply #149 on:]

arghh... thanks for that!

I remembered seeing that code but when checked I saw that it was using the full power, 20dBm!
Problem was I checked on the RX and forgot to check on the TX side, so yes I was only using 1dBm
on the TX side. ;-)
If the weather keeps good, I'll test it again with more power.

PS: What have you used to power the TX module? Both Futaba and 9X output 12v so it needs to be converted. For testing I ended up using a ESC+LiPo. So I was wondering if you have a new board layout that includes a voltage level converter.