openrcforums

Understood
I will check which variables have to be changed to make the autodetect.
Is there anywhere in the code that is good to implement the autodetection function.
In which .cpp file ?

I put on github the latest version of oXs. It is not yet in the branch master but it is in the branch openXsensor_imu
This version includes the automatic detection of the max number of cells being connected. Still I did not tested it.
Changes about this where done in files oXs_voltage.cpp and oXs_voltage.h

Please note that this version of oXs includes many many other changes (HOTT protocol, support of GPS, support of mpu6050 sensor- accelerometer/gyro, ...).
If you use it, please check carefully changes in the config.h file (deactive the option that you do not use)

Another solution that should probably works (depending on the version you where currently using) : copy the 2 files oXs_voltage.cpp and oXs_voltage.h from this new version into the version you are using.
Let me know if you have an issue.

Hi I just tested the new openXsensor new_sport version
and it doesn't send any telemetry data
I've attched my config file
Did I overlook something?

Your config seems ok.
I made so many changes in this version that I expect it should be some bugs.
I tested this version with a baro MS5611 sensor and it seemed ok.
I was waiting for feed back from another user in order to go further.
I will check what happens when there are only voltage measurement like in your config.
I will post here the result of my tests

Thanx
If you need me to test anything please let me know
Also I can try with a board that also has pressure sensor onboard

dschiedsch wrote:Hi I just tested the new openXsensor new_sport version
and it doesn't send any telemetry data
I've attched my config file
Did I overlook something?

I found a bug in this version about calculating cells voltages.
I put a new version on github.

I did not had time to test it. Stil I suspect some other bugs because the correction I made should not explain why VOLT1, VOLT2, ... would not be transmitted.

Hi
just tested the new code
on a board with soldered ms5611 chip.
Doesn't work either. No telemetry reaction whatsoever
Attached is my config again

// --------- 9 - Data to transmit ---------
#define VSPEED_SOURCE FIRST_BARO //

// ***** 4.5 - Vertical speeds calculations *****
//#define VARIO_PRIMARY BARO_AND_IMU //
#define VARIO_SECONDARY FIRST_BARO //

Can you try instead:

// ***** 4.5 - Vertical speeds calculations *****
#define VARIO_PRIMARY FIRST_BARO //
//#define VARIO_SECONDARY does not matter //

VSpeed worked in all combinations for me in the new S-Port branch.

I put new version on github in order to get vfas on SPORT.
Please note that currently only vfas fields can be used to send VOLT_1, VOLT_2, ...

I just put a version on github that allows to transmit VOLT_1, VOLT_2... in more fields than vfas.

Carbo wrote:// --------- 9 - Data to transmit ---------
#define VSPEED_SOURCE FIRST_BARO //

// ***** 4.5 - Vertical speeds calculations *****
//#define VARIO_PRIMARY BARO_AND_IMU //
#define VARIO_SECONDARY FIRST_BARO //

"#define VSPEED_SOURCE FIRST_BARO" is a valid set up. It should works if line "#define VARIO" exist. When I use this set up, I get values on Tx displays for Altitude and Vspeed.

"#define VARIO_SECONDARY FIRST_BARO" is just discarded (it can be commented ot not). It is used only if PPM is activated and if VSPEED_SOURCE ask for "PPM_SELECTION".

Please note that if you are using openTx 2.1.x, you probably have to check the telemetry set up on on openTx because the new sport version uses other sensorID than the other oXs version.

Hi
I just flashed the new version and now I'm getting some telemetry data. But it is irregular and the IDs even for the same information keep changing.
I was wondering maybe this has something to do with the fact that I'm not using an external oscillator on my board but rather the internal RC oscillator.
I have the option to populate an external resonator but haven't done so.
I will try to get one and check.
Also I'm using openTx 2.1.6.
Which version are you testing with?

I am testing with openTx 2.0.13 but Carbo is testing with 2.1.x.
It is strange that the Ids for the same information are changing. This was for sure not what I expected.
I had expected that oXs would send one type of information with only one ID.
Carbo did not reported this issue. I think he will go further with some tests in the next days.

I would have once to upgrade to 2.1.x but it will probably be for next year.

Hi
In the meantime I took an arduino mini pro board running at 16MHz
Here the code works fine
Can it be that the new code require 16MHz clock frequency?

Or should it also work with a more stable 8mhz clock ?

Some options (like USE_6050) requires many calculations and so more CPU. It could be that a 8 mhz processor would not be powerful enough when you activate many options simultanously.
Anyway, as far I know, a 8 mhz processor has already been used successfully for first vario + voltage + current simultanously with the old code.
The new code should normaly work too.

If the new code does not work on your 8 mHz, perhaps can you try once an old code (e.g. version 2.5) on the sma hardware. If it works with the old code and not with the new one, then, we will know that it is a software issue and I can try to solve the issue.
Best is first to compare 2 versions with very basic config options (E.g only one baro sensor or 1 voltage) and if OK, then to continue adding more options and see which combination of options does not work.
Thanks for your feed back.

Hi I tried a basic configuration with old and new code on my pcb and the old code works while the new code (new sport branch) doesn't
however on the 16MHz arduino board both versions work just fine.
Now I don't have a 8MHz Arduino board with the resonator populated so I can't tell whether the 8MHz clock vs the 16MHz clock is the problem or if the rc oscillator inside the atmega which I'm using is just not good enough for the new code. The old code works just fine without the resonator on 8MHz

That is strange.
If the old code works just fine without the resonator on 8MHz and the new one not, I presume it is a software issue in the new version.
Still I do not see where the bug would be.

It is also strange that "it is irregular and the IDs even for the same information keep changing".

In order to further look at the issue, best would be to put a logic analyser probe in the Sport signal and take a trace of the signal.
I do not know if you have such a logic analyser.
I have one but I do not have a 8 mhz arduino to make the test myself.

Hi
Sure enough I have a salea logic
Attached is the captured file
As you can see the sensor is not answering at all (which is what I expected)

Did another capture where one data packet came through
Ids are not changing anymore
But the date is coming very seldomly
Timing seems ok but I guess the openXsensor doesn't properly see the requests and therfore doesn't answer regularly

So after a bit of waiting here is the dlg version of my board
Have a look at the pdf for details
Gerber files are uploaded as well.
Board dimensions are 13,5x25mm
How's this for a small board?

Features vario and 2S lipo measurement

Wow! Looks very good!

What is the purpose to separate VIN on SP connector and BAT + pin on BAT connector? Should they be interconnected? Or at least to have a Bridge that can be shorted to connect them together?

Also, maybe you can rotate on connector to have both GND pads square.

What do you think it will cost?
Pavel

dschiedsch wrote:Did another capture where one data packet came through
Ids are not changing anymore
But the date is coming very seldomly
Timing seems ok but I guess the openXsensor doesn't properly see the requests and therfore doesn't answer regularly

Thanks for the trace.
I hope I found the bugs.
Looking at the trace, I saw that the timing for UART were not rigth.
E.g. when oXs sent the data, the delay for the start bit was too long (I saw it in the trace).
I expect also an error when reading the received signal on SPORT. It should explain why oXs was not sending data most of the time (because he did not recognised the expected bytes from the Rx)

At 16 mhz the error was smaller and oXs stayed within the tolerances for the baudrate.
At 8 mhz we were really at the limit and most of time it was not OK.
Still I do not understand why old version worked because the error was already present (perhaps that there are a few instructions extra in the new one and that makes the difference?)

I put a new version on github to fix this.
I added an extra signal on pin A0 that shows when oXs read the signal or set the output bits. This is useful to check if the timing are right or not.
Take care that this option is activated in the version on github and therefore pin A0 and A1 too !!! are automatically configured as output. So do use this version with a device where external voltages are applied to A0 or A1. it could damage the Arduino.
I checked the version with a 16 mhz arduino and the timing seems OK.
Could you please check if this is ok with a 8 mHz (even without resonator)?
Best would be to connect your logic analyser in order to trace 2 signals:
- the SPORT (as in the first test)
- the signal on pin A0
If this version is OK, I will add the correction to other protocols and I will remove the extra signal on pin A0.

Hi
The new version works like a charm on my board with RC oscillator
Attached I have the logic trace with S.Port and A0 traced.
Of course no cell voltage measurement at this point

Hi
I just commented out the //#define DEBUGASERIAL
and enabled the voltage sensing pins again in the oXs_config.h
tried it and it works perfectly
Thanx for adaptation and support

Thanks,
I will make other updates to day

dschiedsch wrote:So after a bit of waiting here is the dlg version of my board
Have a look at the pdf for details
Gerber files are uploaded as well.
Board dimensions are 13,5x25mm
How's this for a small board?

Features vario and 2S lipo measurement

Board dimensions smaller as arduinopromini
Please integrate 3 small contact-pads (the 4th is VCC from battery) altogehter for 4-cell measurement of NiMH-battery and 2 small contact-pads for TWI-sensor-enhancement
( You do not need contact bar. It´s to be handled flexibly with small contact-pads and with cable connection, for power too.)
Please improve ADC-measurement and add L=10uH on VCC-pin4 and C=100nF on AVCC-pin18 as recommended in datascheet for Atmega328
Please locate properly MS5611 to add tube for TEK viewtopic.php?f=86&t=5856&p=83843#p83775

Hi
I just tested one of the sensors on D-Series receiver.
It works but the VFAS voltage is displayed wrong
Instead of 22.65V it display 206.72V
I think this has something to do with:
https://github.com/opentx/opentx/issues/2607

Ideas ?

Found it myself
It was exactly because of the issue above
changed line 558 in oXs_out_frsky.cpp to
SendValue( FRSKY_USERDATA_VFAS_NEW , (int16_t) (voltageData->mVolt[VFAS_SOURCE - VOLT_1 ].value/10.)+2000);
Now it works nicely

Thanks for the info.
in order to be compatible with oldier version of openTx (or with other firmwares), I propose to solve this isue sending the value in 1/10 volt.
So I would change the line in:
SendValue( FRSKY_USERDATA_VFAS_NEW , (int16_t) (voltageData->mVolt[VFAS_SOURCE - VOLT_1 ].value / 100 ) ) ;

Hi
I updated the schematic and board
pinout on Sport and batt conector are now the same and there are jumpers for 1S and 2S configuration

Concerning the recommendation from Tempo
I'm not quite sure
So you want a 10uH and 100nF from Vcc to AVCC right?
Also all the pinheaders should be replaced with test-pads
What diameter should they have? 1mm ?

concerning cost.
I think you could build the board for ~10€ cost if you build a sufficient qunatity e.g. 20