openrcforums

No, you actually you don't have to join them together to one big file. The .ino file is just the one file that is already there and that you have to open in the arduino IDE. It will include all the files automatically based on the configuration you choose when you compile it. The new openXsensor is ...

you managed with the openXvario... so the only difference here is that you have to download all these files here instead of just one .ino file ...

Where do you learn how to do this? I downloaded the files through raw files one at a time. They compile ok in arduno. I put an SVN reader on my win xp but do not know if it is needed or how to use it. in my opinion you only need a SVN client if you want to develop yourself. In future releases i am ...

You can use the Frsky dashboard, it supports the oXv/oXs. You will get altitude information, cyclic voice readouts, you can add a voltage divider for voltage measurements. And I guess/hope espen will implement the vario as well in one of the future releases. Gesendet von meinem GT-I9300 mit Tapatalk...

that compile error refers to some jeti code, which is only in a seperate directory, so i am confused why you should get that error message.... -did you download all the files into a clean directory? the file being refered to "openxvariojeti" is not included in the openxSensor directory on ...

In version 191 I'm getting compile errors with: openxsensor: in void setup() 'INPUT_PULLUP was not declared in this scope in openxvariojeti: in void setup() JetiUartInit() was not declared in this scope while openxvarioplay and openxvario compile without errors. Up to now, I never tried to compile ...

As mentioned before, i am working on a new version of the oXv called openXsensor. i did not have the time to create wiki entries or other documentation, but in case you want to give it a try, you can download all the files from here: https://code.google.com/p/openxvario/source/browse/#svn%2Fbranches...

Hi Gryse,
Welcome to the board!
i used the oXv together with frsky dashboard. it worked fine, but you will be missing the vario sound.
The oXv does not support decoding the ppm stream for servos.
Rainer.

Ohh! ... I know that this is the wrong place to ask.. But.... Has the software been done to allow us to use a voltage sensor and a current sensor with the Arduino? The new version of the oXv is the openXsensor. Its in a seperate folder on google code, you can downoload all the files in there and up...

oops

@kilrah: thanks, going to have a look at that.
@Joao: great, thanks for the flight report. good to see that you finally got a glider and didn't crash it

yes, I had one of those as well. Worked fine, just a bit bigger then the other one.

Gesendet von meinem GT-I9300 mit Tapatalk 4 Beta

Hi, I am new here but am very excited about this project. I would also like to use this vario not only in my RC gliders, but when Paragliding. Is it possible to make a stand-alone version without the transmitter? So only with the Sensor and the Arduino connected to a buzzer, or even better to a buz...

timv wrote:why do my posts take so long to show up? is there some verification i need to do?

Hi timv,
and welcome to the board!
All posts from new users posts have to be approved by a moderator to avoid spam.
regards,
Rainer

@flaps: for planes that land on/in the water? Interesting ;-) @jbabio: Nice idea! if you want to start coding, please do it using the openXsensor code. its much easier to implement a new sensor there. If you need help or guidance, i can help you best would be to clone e.g. the current sensor class a...

just paid my taranis....

Hi Jochen,
the upcoming new version called openXsensor will have exchangeable output modules, so technically only one class has to be adapted. i don't have any Graupner HW, so we would need somebody with the HW to give it a try. If you want to try, i would be willing to help you.
rainer.

Rainer, above I think you forgot a feature already present on the oXs.. You mentioned the BEC voltage but not the pack voltage which we can also read and send down to the tx.. ;) Also, a nice GUI for the sensor would be the icing on the cake :mrgreen: ;) João the voltage divider value will be trans...

Slight aside, I wondered about the consumed capacity. Do you really need 65Ah? I was thinking put this in the FUEL field, with the MSb set and the remaining 15 bits as 0-32767 mAh. This would be easy to detect instead of 0, 25, 50, 75 and 100 of the FrSky fuel sensor. Mike. i am actually transferri...

no, won't work. And even if it would work, it would have a too low resolution(+/-1m)
rainer.

Yes true. i rearranged the bits above and icnreased to 32 possible units. If we decide to go this path. Would it be possible in er9x/opentx? how manny telemetry fields could realistically be added using this method? ( maybe board dependent... on 9x stock just <n> and on better boards a bigger amount...

units could be the following: 00 none no unit specified 01 V Volts 02 mV MilliVolts 03 A Ampere 04 mA Milliamps 05 m/s Meters per second 06 kmh Kilometers per hour 07 m Meters 08 mAh Milliamphours 09 W Watt 10 ft Feet 11 C Celsius 12 F Fahrenheit 13 mi Miles 14 mph Miles per hour 15 rpm Rounds per m...

yes i took a wrong word there i'll edit my post above.. it should read: Byte 2 will be split into different values - the highest 5 bits are used to define the range UNITS from an enumeration of 32 possible values - the 6th bit will be used to define if this should be treated as a signed or unsigned ...

How about the following idea: we choose how many new generic data fields we want. some are 16bits big, some are 32 bit. each will be presented as 1(low precision=16 bits) or 2 (High precision=32 bits) new IDs in the protocol We then take one additional new ID to use as the setup ID. this ID transmit...

I think we already tested using the high IDs, but we didn't receive anything on module side! Must be double checked. On stock board I am also in favor of reusing the IDs. If we don't do that, we will have to implement a new routine to decode and store the telemetry data. It will cost flash ... Now ...

Given that FrSky are going down the SPORT route, they are unlikely to add to the existing HUB sensors or to those sensors that send serial data using the HUB protocol without the hub. There are a number of currently unused IDs in the HUB protocol, 7, 8, 10, 11, 12, 13, 14, 15, 29, 30, 31, 32 as far...

yes, but still this would not provide new telemetry fields to transfer pre-calculated data like mAh. For data coming from a sensor using a pic , ardiuno or whatever, there would probably not be the demand for offset multiplier and divisor, this would apply more for anaolg inputs. The generic data fi...

Basic question: I know that the receiver repackages the data that it reads via its own serial input. As an example, the datastream that the FrSky Sensor Hub sends to the receiver has a different protocol than the protocol the receiver sends via rf to the ground station. So, does the receiver really...

if e.g. ram is too limited to have user definable names for fields, wouldn't it be possible to use companion to add those field names to the Flash before programming? via defines on the compile server or via direct modification of the binary?

idea#2 above for example. this would mean e.g. <n> new ID's that would be treated in the tx similar to the A1/A2 today. we use the tx/groundstation to define the unit, number of decimals and the name. then we could have working voice readouts including correct units. and we would only have to put <N...