getting none inverted data sent from openxsensor to rx

[nigelsheffield]

hi, there is midelics diy rx which he is writting code for hub telemetry now, his code runs on rx-f802 which i am testing for him whilst he makes the code , would the inverted hub data be easy to change to none inverted for simple connection to his rx, if so how?
thanks
nigel.

discusion here on the hub code for rx.
http://www.rcgroups.com/forums/showthre ... st33297096

[MikeB]

It should be possible. The SPort serial is software driven, and I thought the hub is as well.
My question would be, since a real hub sends inverted data, then why does the receiver not accept inverted data?

Mike.

[mstrens]

in oXs, all protocols (Frsky SPORT, Frsky HUB , HOTT and Multiplex) are supported by software.
So in theory, it should be possible to support none inverted. Still this would add some complexity to a part that is already quite complex and then the Rx would not be compatible with HUB device.

[midelic]

well because the rx is avr based and use hw serial.openx sensor using sw serial and from what I see iin the code is simple the change from inverted to oposite.the other solution is to change my serial from hw to sw,, don.t want to do that. regarding using original frsky sensor people using it have always an inverter around.
so I think in the end ill make a version of openx serial with normal signal.it is simpler for me like that
btw the change is not complex at all actually oposite Mike can confirm that,

[jhsa]

That would be just an option in the oXs config file, right?

João

[midelic]

it can be I wonder why nobody think of it before.it is not complicated.i started recently checking this sensor code,

[MikeB]

regarding using original frsky sensor people using it have always an inverter around.

I don't agree with that statement, in fact I would say the opposite.
I would say it is better to add an inverter at the input of the rx to be compatible.
Or use a software serial input. Since this is only at 9600 baud, that is not too difficult. The openXsensor uses a software serial at 57600 baud, driven by an interrupt.
Particularly, if you have a timer capture interrupt for this, I have code in ersky9x that handles software serial with very little impact on the processor.
Why make everyone who wants to use hub data fit to your receiver? A FrSky receiver expects inverted serial data, why not yours?

Mike.

[midelic]

I think is a confusion I made code for an existing rx it is not me making it ior selling it.So installed an inverter on this rx is irellevant ifor me it is equivalent with people (i'm one of them)using it with itheir own inverter.serial code itself it is easy to make.the problem is I stuffed a lot of things inside,.......telemetry,ppm sbus out,i need to test and make sure all woking fine togheter,atm I working with hub telemetry and I need a quick source of not inverted sensor signal for test.
nigel already posted here in the same time I had a read of openxsensor code, and realized it is easier to change.if sooner maybe he would not disturbed you guys.
I wiil make the mod and use it.thanks for the tip with serial in ersky9x
regards,
m.

[Kilrah]

it can be I wonder why nobody think of it before.it is not complicated.

Because there has never been a need for it, all receivers it's been used with so far expect the "correct" signal polarity

[nigelsheffield]

i Built a simple inverter for now with a bc546b and some resistors for testing hub data, its only one way right?
so the inverter has the advantage of being able to level shift too which is handy.
once s.port data is attempted on this rx though a 2 way inverter would be needed unless its implemented in s/w on either sensor or receiver..

I thought it might take less processing power too if neither signal was inverted but of course the problem is maintaining compatibility with normal frsky gear.

[midelic]

about need.... what if feed directly the actual openx sensor on turnigy 9x with er9x frsky to see hub telemetry on er9x screen what do I need......
the future to be signal modification on openx sensor is trivial.i don'T understand where is the problem.it is not like i ask somebody of you to do it for me.we share ideas here.
you are right it is "corect "polarity right now...few years back was oposite.

[MikeB]

The openXsensor, like the hub, sends the telemetry data as a set of bytes to the receiver.
The receiver packages these into "user" telemetry frames. These are what are received and processed by er9x.
Sending the serial data from openXsensor (or the hub) directly to er9x doesn't work.

While inverting the serial data from the openXsensor is easy, the same is not true for the FrSky hub. It depends on what you are trying to achieve. If you want a receiver that works just with openXsensor, then having the openXsensor send non-inverted serial is fine, but if you also want to use the FrSky hub, then you need to handle inverted serial somewhere.

Mike.

[nigelsheffield]

I think for simplicity of getting code and testing it on the RX Midelic has no time to build an inverter but is travelling and has time to write a little change of code for openxsensor and then can test it quickly when he is home.
Also the tx and RX pin for the 328 processor on reciever is there to connect to.
I have built inverter for now...

On subject, arent there some flight controllers which need an inverter to give frsky telemetry to RX? Maybe The ability to use either inverted or none inverted data with the RX would be an advantage there, his RX code outputs s.bus in none inverted so easier to use with your s.bus decoder mike.0

Later when it's all working perhaps using soft serial and invert it that way using mikes method with little impact on processor could be tested ..

Another idea I had but I am not sure processing power and memory is there was to impliment the altimeter/vario code on the RX own 328 processor allowing a very small footprint RX and altimeter/vario ,

[jhsa]

What about reading the voltage? Not everybody fly (only) gliders . At least a couple of analog inputs are needed, for reading voltage and temperature, or RPM, current, etc..
Best would be if it could also read single cells.
Altitude and vario only is useless for me for example..

João

[nigelsheffield]

The rx-f802 has 2 analogue inputs already, one is divided down so that a 3 cell lipo can be connected , the other just up to 3.3v.
I guess the other sensors would take up space when the idea of this RX is that it is small and cheap and catering for lots of different sensors might take too much processing power I don't know , the 328 has plenty of connection but lots taken up already by the servo pins and rf connection.
Though if using s.bus those servo pins could be reused for telemetry sensors maybe?

[nigelsheffield]

Oh and I was thinking of just the altimeter/vario for a dlg in particular , maybe just use a bmp180 and forget vario part, just use altitude for launch heights.
A bmp180 cost 60 pence and is tiny and weighs virtually nothing.

[jhsa]

If processing power is a problem then a way to connect oXs is needed.. Otherwise it will be a RX only for DLG planes

João

[nigelsheffield]

That is what Midelic is doing right now and why he wanted none inverted hub data.
But a verrsion of the RX code for just a bmp180 for altitude would mean you have the option of burning different fw version for whatever you want to use it in, the rx-f801 for instance is £7 , add a bmp180 for 60 pence and you have a tiny cheap RX for those small home built dlg planes or if you are limited to 400ft altitude and need to know when you are getting near this would be a cheap solution IF it is feasible.

[midelic]

I know that directly will not work .....but with serial inverter HW or SW....

Sending the serial data from openXsensor (or the hub) directly to er9x doesn't work.
Mike.

[MikeB]

Still no, the format of the data is different. The hub data stream appears 'packaged' in telemetry user frames when sent by the Tx module, and that is what er9x/openTx expects.

Mike.

[midelic]

I assumed(without checking properly) .....that openx/hub sensor sends data in the same user format with 11 bytes(7E header/tail. ID.+8bytes).
Now I see I was wrong.In fact it is simpler the sensor sends only a bunch of ID's and values bytes.Now I know why my hub implementation in RX doesn't work.
Thanks Mike!.

[MikeB]

Just the confirm the hub data is 0x5E ID data-low data-high 0x5E ID data-low data-high 0x5E . . .
But also, 5D and 5E values in the ID and data are "byte stuffed" to 5D 3D and 5D 3E.

Mike.

[midelic]

Yes,... I know in fact it is hub data "naked".Bytes are sent already stuffed.
For some reason I was misled.I believed that the hub is using hub data in telemetry user package.
I red that hub pdf and it said nothing about serial speed or serial frame data...so I assumed it is assembled in user frame.
My mistake.
Thanks again.
I assume that the serial speed is still 9600 for hub(I don't want to calculate timers registers data now).


In fact I'm thinking to add an option(in config) that openx sensor data to be read by Er9X TX.That means add bytes for user frame,It doesn't seem complicated It will allow to me to see telemetry data directly on er9X screen without RX involvement.Just for test sensors fast.

BTW the receiver doesn't package the hub data in user telemetry frame.
Actually receiver sends data as is.The tx module at the other end is packaging data in user frames and sends data to er9x.
It is what I'm doing now telemetry in multiprotocol module.

[MikeB]

Baudrate is 9600.
There is a compile option for er9x (N2F). I don't think I created it, but if N2F is defined, you should get a version of er9x that recognises raw hub data, treating 5E ID data-low data-high as a frame!

Mike.

[midelic]

Excellent thanks.

[ReSt]

If you check the "N2F" code in frsky.cpp in one chapter you will find a compile parameter "#if defined(HUB)"
I did introduce this to deal with a characteristic of my special telemetry rx/tx modules (APC200).
When there was a "0x18" hex value in the datastream, the character following the 0x18 was sent twice. This #if defined(HUB) function skipped the one (additional) character.

I used N2F to send altitude data from OXS (version <=r240) to my radio and I had to invert the data that the OXS sends. As OXS used a software serial, this is easily done changing

SoftwareSerial mySerial(0, PIN_SerialTX,true);
to
SoftwareSerial mySerial(0, PIN_SerialTX,false);

Reinhard