Thread Tools
Aug 06, 2017, 01:42 PM
Durability Tester
if you can find a way of getting full mavlink to work this will be the best lrs system for a pixhawk out there, all that is needed is flow control then you can get all the messages down.
Sign up now
to remove ads between posts
Aug 07, 2017, 08:47 AM
Registered User
Thread OP
Ask and you shall receive

New version 1.10 is available, now you can use SBUS and lbeep

i also made some improvement to resyc process, if only single package is missed, radio tries to receive next (in fact freq no increased by 2) channel instead of waiting 10 times package lenght for next transmission... If more then single package is dropped, full sync is done...

lbeep was very useful for packages drop debuging.... now i'm going to use rf generator or another tx module to simulate real signal interferences...

Krzysiek
Aug 07, 2017, 08:52 AM
Registered User
RocketMouse's Avatar
Amazing! Thanks.
Aug 07, 2017, 09:35 AM
Registered User
Thread OP
Quote:
Originally Posted by ABLomas
OK, so it's raining again, back to PC ;-)
Flew smth like ~100km over this time, all time on minimum power (if i still believe that i can change power with some channel). I can say that in some situations QLRS works better than OLRS (even 250mW vs 1W), that's good.
Now my personal comments about system (not trying to steer development in any way, just providing feedback):[LIST=1]
Thanks for testing

Quote:
Originally Posted by ABLomas
Range is fine, but RSSI is still something "guess what happens". It does not drop below 50% with my calibration (means "PWM value on output channel does not drop below smth like 1200 value" or smth) but one time with 50% i can have fine control, another time it's barely controlable, with huge delays and glitches. So, simple packet counter would def. be better, because "50% is not equal to 50%" ;-)
You should not expect big rssi changes, especially when SNR mode is selected... Now you can use lbeep

Quote:
Originally Posted by ABLomas
While it's cheap and nice - it's still closed source, one man project, which means "use it while it works but be prepared to toss away everything". This really limits usage - should not be used on serious "long-living" planes (oh, add all that #drama on ULRS - the same situation, where project is in one man hands - everything suddenly becomes unusable and...)
Sorry, but currently there is no any developer interested in development, so sharing code only to starts someones commercial kick starer is not what i want to do
When I decide to stop development and there will be some not fixed bugs, i will release source code, don't worry.
If you are interested in any particular piece of coding i can share it no problem...


Quote:
Originally Posted by ABLomas
Failsafe/link loss/packet loss feels strange. I'm using 1s delay on OLRS, i guess, should set 1s here, too, because in heavy packet loss condition (? - i'm not sure, because i did not entered failsafe, even once) plane is not controllable anyway. From power to TX module to full control you still need ~3-4s, so it's better to have AP steering plane and controlling attitude.
I made some correction to sync routinges, and thanks to lbeep i fill difference now Please try latest version. And of course AP steering plane is much better and safer for testing

Quote:
Originally Posted by ABLomas
Probably some kind of proper checksumming over link would help, but this is not critical anyway.
In short - you are flying with 50% failsafe, plane suddenly starts to swing in both directions, sometimes loosing pitch. You can't control it properly, as delays in such packet loss conditions are huge, few seconds until next command, so - you aren't in failsafe, but plane is not properly controllable, as next command arrives when it's not required anymore =)
well, checksum is calculated and attached to every package, the problem may be connected to incorrect PPM generation/reading. Try now with sbus protocol selected.
Btw, maybe FC is not handling fail safe correctly, after entering fs, it should stay in this mode, during changing flying mode to manual... so if you select let say stabilize by your taranis's switches, and fs occurs, and even when it signal is back again, your plane should stay in fail safe (rth?) mode till you decide to switch to manual...

Quote:
Originally Posted by ABLomas
Higher frequencies def. helps, i can still see random dots with diagonal lines sometimes, but that's not even close to earlier setup. If someone using 1.2G - check allowed freq in your country and if possible - move above 436MHz. I did not used filtering here, keeping TX antenna ~40cm from RX antenna - not bad.
good

Quote:
Originally Posted by ABLomas
While current setup is really cheap - module size limits it's usage. Let's say, we don't need telemetry, so can we just wire small lora module and M0 on it's back? OLRS RX is 16x16mm - perfect for long range mini-copters; 100mW lora module has similar dimensions.
If this is not possible - maybe there is another, smaller power module which can be adopted without spending much time? For example:
https://www.aliexpress.com/store/pro...800411620.html
I already have such a modules (1W version) and thinking about small pcb and....

Quote:
Originally Posted by ABLomas
Current HW is still in "needs more testing" stage. Spent so much time chasing issues and everything turns to be faulty modules. But maybe i'm just unlucky and all future purchases will be nice ;-)
Thanks for cooperation
Aug 07, 2017, 12:27 PM
g0t rabb1t?
ABLomas's Avatar
Wow, nice changes, will flash ASAP.
Too bad, weekend ended, so can't test quickly, but i will try.

I also tested lower failsafe value in air, feels a bit better (can clearly "feel" when plane enters failsafe, instead of wobbling forward-back), but this is prob. useless experience as new firmware will change everything ;-)

If RSSI stays the same, then for other users - set RSSI range on OSD as 270...600. Then you will know, that ~20% is link-loss condition (varies slightly, so not exactly "0" and ~30% is still flyable.

Also small note - while frequencies posted earlier work fine with 1.2G video - they still interfere with runcam split. I set sTelFrmR to 1024 and lTelFrmR to 1024, so still getting telemetry frames (rarely), but even single telemetry frame 40cm from RX (working as TX) still kills video from runcam (screencam attached), so filters on RX side are still required. Not a big deal for me, as i do not need telemetry (yet).
Aug 07, 2017, 01:13 PM
Discovering the joys of flying
Adilson's Avatar
Hey there

I've been following this thread for a while and I think what is really missing in the current LRS market is the ability for is a symmetrical link with full support for telemetry either Mavlink or FrSky (smartport) at least as ardupilot and others like inav use it. There were other attempts but they kinda stopped for one reason or the other and I am quite quite impressed by how fast this is progressing but looks like there is a hardware limitation that I think will prevent the "full telemetry dream" correct?
In any case, my wishes of best luck.
Aug 08, 2017, 03:35 AM
Registered User
Thread OP
Quote:
Originally Posted by ABLomas
Also small note - while frequencies posted earlier work fine with 1.2G video - they still interfere with runcam split. I set sTelFrmR to 1024 and lTelFrmR to 1024, so still getting telemetry frames (rarely), but even single telemetry frame 40cm from RX (working as TX) still kills video from runcam (screencam attached), so filters on RX side are still required. Not a big deal for me, as i do not need telemetry (yet).
Hi,
I have similar problems with runcam 2 connected to minim osd, but only together with osd, without osd everything was perfect.
I solved the problem using two ferrite rings, one for wires going to lrs, 2nd on data/power wires going to osd



and one more thing, run cam split, has no shielding on wires going from cmos module, to main board, you can try using type like 3M CN-3190 ...

btw, i just got 1.2GHz interference measurements from manufacture, and it looks ok.





I wonder maybe they use different spreading factor/bandwidth ....

Krzysiek
Aug 08, 2017, 04:25 AM
Registered User
Thread OP
Quote:
Originally Posted by Adilson
Hey there

I've been following this thread for a while and I think what is really missing in the current LRS market is the ability for is a symmetrical link with full support for telemetry either Mavlink or FrSky (smartport) at least as ardupilot and others like inav use it. There were other attempts but they kinda stopped for one reason or the other and I am quite quite impressed by how fast this is progressing but looks like there is a hardware limitation that I think will prevent the "full telemetry dream" correct?
In any case, my wishes of best luck.
Hi,
I think full directional mavlink "like" link could be supported, but current hardware (low ram memory for data buffering) will never support it.
I'm gonna develop small pcb with more powerfull MCU, and make full telemetry possible...
Aug 08, 2017, 05:47 AM
Registered User
RocketMouse's Avatar
Can you please show your PCB layout so that we can also try to offer any ideas before it will be finished?
Aug 08, 2017, 06:25 AM
Registered User
Thread OP
Quote:
Originally Posted by RocketMouse
Can you please show your PCB layout so that we can also try to offer any ideas before it will be finished?
Of course, but first maybe we can complate requirements....
I think that following features hardware related should be supported

1) PXX, SBUS, CPPM
2) fail safe, lbeep, rssi channel injection
3) 4 PWM outputs ???
4) serial port for telemetry
5) serial port for debuging/setting
6) status leds 1-2-3 ????
7) usb for firmware update??
8) remote/radio firmware update/change settings in slave devices (rx), directly from master (tx) module.... i hate when i need to remove anything from my planes....
9) connector for redundancy rx
10) step down converter??? i'm not sure.... it will incrase rf noise....
11) what type of rf connector ? maybe smaller one ?


btw, just found bug in single servo mode, and did update.... (new files availalbe)
and in single servo mode, power selection does not work... gonna fix it

Krzysiek
Last edited by qczek; Aug 08, 2017 at 06:34 AM.
Aug 08, 2017, 06:57 AM
Registered User
RocketMouse's Avatar
I see outputs like that:
1. CPPM/SBUS out with a soldering pads for inversion.
2. RSSI out with filter
3. Lbeep out
4. 4PWM

Other:
1-4 Great!
5. Just pads maybe
6. For TX - power mode different speed blinking, all the rest not important for me
7. Not sure, that's not very often procedure but will be more pain soldering
8. Great!
9. What is that?
10. Not sure too.
11. Common SMA for better compatibility with already made antennas.
Aug 08, 2017, 07:20 AM
Registered User
9. would be one of the most important features - diversity. The entire list looks great to me.

Two things I'd add is the ability to map the power level to a physical switch and bluetooth for extracting telemetry ground side.
Aug 08, 2017, 07:26 AM
Discovering the joys of flying
Adilson's Avatar
I would not use USB. We can use FTDI, the USB connector is fragile and it's one more chip to add cost and complexity.
Aug 08, 2017, 07:58 AM
Registered User
RocketMouse's Avatar
Quote:
Originally Posted by scotty562
9. would be one of the most important features - diversity.
Diversity will make it very complex. Better to connect second receiver as a satellite, but this is all not really needed.

Quote:
Originally Posted by scotty562
Two things I'd add is the ability to map the power level to a physical switch and bluetooth for extracting telemetry ground side.
These are very good ideas.
Aug 08, 2017, 08:07 AM
Registered User
Thread OP
ok, how about size,



1W module without MCU is almost same size like current hardware it's 37x25mm

Krzysiek


Quick Reply
Message:

Thread Tools