openrcforums

Posted: **Mon Mar 14, 2016 3:04 pm**

Comprende!

Posted: **Mon Mar 14, 2016 6:13 pm**

@mstrens.

In ver. 6.1 in oXs_config.h I find that line here

#define SPORT_SENSOR_ID    28 // value must be between 1 and 28

This line has been omitted in oXs_config.h ver. 7.0, but I think, still necessary when using more then 1 oXs on FrSky_Sport in my opinion.

br KH

Posted: **Mon Mar 14, 2016 6:50 pm**

In version 7, there is normally no need anymore to define the SPORT_SENSOR_ID.
In version 7, oXs uses several predefined sensor Id ( one per type of data) . In most cases, there is no need to change the default sensor Id.

Still, if you really want, you can change some of the sensor ID. There are defined in file oxs_out_frsky.h

Posted: **Mon Mar 14, 2016 7:44 pm**

OK. Understood.

Think, I have to make a note in my pocketbook.

br KH

Posted: **Mon Mar 14, 2016 8:48 pm**

mstrens wrote:In version 7, there is normally no need anymore to define the SPORT_SENSOR_ID. In version 7, oXs uses several predefined sensor Id ( one per type of data) .

This should not be done that way. Each physical device must answer to one ID only. We were pretty much done correcting all projects that originally did that mistake, and now the only one that was correct from day 1 goes backwards

Posted: **Mon Mar 14, 2016 9:57 pm**

One oXs supports nearly all sensors and so can generate nearly all telemetry fields :Alt, Vspeed, RPM, current, temp, cells, airspeed, all GPS, all ACC.

Instead of sending all telemetry fields in reply of only one sensor Id (which does not allow to transmit many data per sec), I now use one sensor Id per group of fields but just in the same way as the FrSky devices.
E.g. oXs use one sensor ID for Alt and Vspeed, one another ID for all cells, one another ID for all GPS data, ...
In the "worst" case, oXs uses 6 sensor ID.
Telemetry fields of the same group (e.g. Alt and Vspeed) are always sent in reply of the same sensor ID (normally the default Id used by Frsky for a device providing this group of data).

This seems me conform to the stardard rules taking into account that one oXs device provides the data that normally requires 6 Frsky devices.

In the special case where a user would like to implement 2 physical devices to send the same type of data (e.g. for 2 X 6 cells), it is possible to change in one of the oXs the sensor Id for this group of data (just in the same way that you can change the sensor ID of a Frsky sensor).

Do you see an issue with this process?

Posted: **Mon Mar 14, 2016 10:35 pm**

Kilrah wrote:This should not be done that way. Each physical device must answer to one ID only.

In general that is true, but I would agree with mstrens in this case that this may be one physical connection on the SPort, but is really more than one physical device.

Mike.

Posted: **Tue Mar 15, 2016 6:45 am**

Have to admit, the "old" way with ID was clear to me. But seeing mstrens explanation 2 physical devices to send the same type of data (e.g. for 2 X 6 cells), ... Makes sense ....

@mstrens. But could you, next time you look into oXs_config_description.h, take that passage out, or rewrite the passage please.
The first sentence left me with lots of question marks.

Code: Select all

*      In SPORT protocol, there may be several sensors connected on the same bus (e.g. a GPS) but each sensor must have a different SPORT_SENSOR_ID.
*           For SPORT protocol, oXs uses up to 6 SPORT_SENSOR_ID. The 6 SENSOR_ID used by oXs are :    
*               DATA_ID_VARIO  0x00  // = sensor 0
*               DATA_ID_FLVSS  0xA1  //          1
*               DATA_ID_FAS    0x22  //          2
*               DATA_ID_GPS    0x83  //          3
*               DATA_ID_RPM    0xE4  //          4
*               DATA_ID_ACC    0x1B  //          ?

Posted: **Tue Mar 15, 2016 6:46 am**

mstrens wrote:Do you see an issue with this process?

Yes!

MikeB wrote:this may be one physical connection on the SPort, but is really more than one physical device.

But it's precisely only the physical connection to the SPort that matters. That "physical ID" is only meant for one thing, which is moderating bus access. Each physical device needs to have a different one so that when the receiver polls an ID only one device connected on the bus will answer. oxs might emulate many sensors, but it is still only one physical device that obviously won't cause bus conflicts with itself, so it makes no sense to use multiple physical IDs for it.

mstrens wrote: Instead of sending all telemetry fields in reply of only one sensor Id (which does not allow to transmit many data per sec)

You get the exact same bandwidth by using one ID as by using many.

Posted: **Tue Mar 15, 2016 8:15 am**

Case 1: You have different sensors with different IDs, S-Port polls the IDs and the sensor answers.
Case 2: You have an oXs with different sensor IDs inside, S-Port polls the IDs and oXs answers.
Does the S-Port-protocoll notice any difference? In both cases you can not connect additional sensors with the same ID, in case 1 you have to change the ID in the sensor, in case 2 you change the sensor ID in the sketch.

It seems equivalent for me.

Posted: **Tue Mar 15, 2016 8:22 am**

I think I remember reading that there was a time limit for one id to send all its info, having loads of sensors on one id made it difficult to send all the data within that time limit and that was why there needed to be different ID used within the sensor?

Posted: **Tue Mar 15, 2016 9:24 am**

nigelsheffield wrote:I think I remember reading that there was a time limit for one id to send all its info, having loads of sensors on one id made it difficult to send all the data within that time limit and that was why there needed to be different ID used within the sensor?

This is not the issue.
As far I know, in SPORT, when a device get a polling for his own sensor_Id, he has a time limit to provide his answer but his answer contains only 8 bytes The 8 bytes are :
- 0x10
- 2 bytes to identify the field being tranmitted
- 4 bytes for the value
- 1 byte as checkdigit.
In some cases there can be extra bytes because when a byte is equal to 0X7D or 0X7E, it is replaced by 2 bytes.

When a device has several fields to transmit, it can only transmit one field per polling it get.
So, if it has 6 fields to transmit (e.g. for GPS), it requires that the device got 6 polling.
The Receiver that manages the polling does not send 6 time the same polling after each other but it alternates in some way the polling code (= sensor_Id). There are 28 sensor_Id polled by the receiver but when the receiver sees that a device replies on a sensor_Id, the receiver send more often this sensor_Id. This allows to get a better use of the bandwith.

Posted: **Tue Mar 15, 2016 9:45 am**

Carbo wrote:It seems equivalent for me

In general yep, but case 2 doesn't respect the spec, doesn't play nice if you want to chain more sensors on the bus, and is pointless given you gain absolutely nothing by doing it that way.

The receiver always polls alternatively one "known" ID and one "unknown" one. If only one sensor is present on the bus it will always get half the polls regardless of the number of IDs it answers to.
The only way you could increase (double) bandwidth (at the cost of having to be the only sensor on the bus) is to respond to ALL IDs.

Posted: **Tue Mar 15, 2016 11:17 am**

Here is a native scan of an oXs with Vario, airspeed and GPS. Only the placeholders Tmp1 and AccX-Z have to be manipulated, the rest is already perfect. If oXs sends everything with one sensor-id, does openTX still know the unit, the precision and the routines to use the data? This is my only concern, bandwith was never an issue for me, even with 10Hz GPS everything worked flawlessly.

Sorry in advance, if this is a silly question, i am only an excited user of openTX and oXS, not able to search for the answer in the code(s).

Posted: **Tue Mar 15, 2016 12:15 pm**

Kilrah wrote:The receiver always polls alternatively one "known" ID and one "unknown" one.

NO (I didn't think it did that!). I've just run a test:
An X8R with a FLVSS and a VARIO on the SPort, while monitoring the SPort transactions.

The X8R clearly did:
Read VARIO (ID 00)
Read FLVSS (ID=01)
Poll unknown ID
Read VARIO (ID 00)
Read FLVSS (ID=01)
Poll next unknown ID
Read VARIO (ID 00)
Read FLVSS (ID=01)
Poll next unknown ID
......

So using more than one physical ID does result in increased throughput, so there is a gain.

I do feel that using more than one physical ID, when the sensor is performing more than one type of function (e.g. Vario and FLVSS) is therefore valid and will improve performance. Using more than one ID for the same function is not a good idea.

Mike.

Posted: **Tue Mar 15, 2016 12:32 pm**

I agree with Mike and that is the reason why I change oXs in this way.

Posted: **Tue Mar 15, 2016 4:09 pm**

Weird, I remembered the other method... might be mixing things up.

Still just as wrong to answer multiple IDs IMO.

Posted: **Tue Mar 15, 2016 4:43 pm**

I see three physical arrangements that are functionally the same:
1. Two completely separate sensors.
2. Two separate sensors (each with its own processor), physically on a single PCB that share a common cable connection.
3. Two separate sensors on a single PCB that share a processor and a single cable connection.

I would say it is reasonable that each sensor responds to its own physical ID. You get exactly the same functionality in all three cases.
In cases 1 and 2, you have to have separate physical IDs, why should case 3 be any different?

I would agree it is not reasonable to respond to more than one physical ID just to increase throughput, and randomly send application data regardless of which physical ID was polled.

Mike.

Posted: **Tue Mar 15, 2016 5:03 pm**

Again because while cases 1 and 2 require different IDs to work properly that requirement isn't present in case 3, so there is no reason to adopt it... and if the user wants to connect a sensor that uses its normal ID together on the bus he is then unnecessarily required to mess with changing IDs.

Bandwidth is the only argument for it, but in practice is irrelevant as there is no need for it in the first place in any kind of normal use.

Posted: **Thu Aug 18, 2016 5:17 pm**

Hey,
Sorry for taking this post a bit off-topic. I have a 4525D sensor and I am trying to get the pressure differential in psi using arduino. The code seems hard to follow for getting the data from this sensor (I am new to I2C sensors). I would really appreciate if someone could help with just a general sketch of getting the pressure differential.

Posted: **Thu Aug 18, 2016 6:23 pm**

In openXsensor the code for reading the ms4525 is in file named oXs_MS4525 (.cpp and .h).

Otherwise looking on the web, I found a post at
https://forum.arduino.cc/index.php?topic=309653.0

Here some code extracted from this post.

Code: Select all

//#include <WireMW.h>
#include <Wire.h>   //I2C library 0x28H 
byte fetch_pressure(unsigned int *p_Pressure); //convert value to byte data type


#define TRUE 1
#define FALSE 0

void setup(void)
{
  Serial.begin(9600);
  Wire.begin();
  delay(500);
  Serial.println(">>>>>>>>>>>>>>>>>>>>>>>>");  // just to be sure things are working
}

void loop()
{
  byte _status;
  unsigned int P_dat;
  unsigned int T_dat;
  double PR;
  double TR;
  double V;
  double VV;
  while (1)
  {
    _status = fetch_pressure(&P_dat, &T_dat);

    switch (_status)
    {
      case 0: Serial.println("Ok ");
        break;
      case 1: Serial.println("Busy");
        break;
      case 2: Serial.println("Slate");
        break;
      default: Serial.println("Error");
        break;
    }


    PR = (double)((P_dat-819.15)/(14744.7)) ;
    PR = (PR - 0.49060678) ;
    PR = abs(PR);
     V = ((PR*13789.5144)/1.225);
    VV = (sqrt((V)));

    
    TR = (double)((T_dat*0.09770395701));
    TR = TR-50;
    
  
    
   Serial.print("raw Pressure:");
   Serial.println(P_dat);
   //Serial.println(P_dat,DEC);
   //Serial.println(P_dat,BIN);
   Serial.print("pressure psi:");
   Serial.println(PR,10);
   Serial.print(" ");
   Serial.print("raw Temp:");
   Serial.println(T_dat);
   Serial.print("temp:");
   Serial.println(TR);
   Serial.print("speed m/s :");
   Serial.println(VV,5);
  



    delay(1000);
  }
}

byte fetch_pressure(unsigned int *p_P_dat, unsigned int *p_T_dat)
{


  byte address, Press_H, Press_L, _status;
  unsigned int P_dat;
  unsigned int T_dat;

  address = 0x28;
  Wire.beginTransmission(address);
  Wire.endTransmission();
  delay(100);

  Wire.requestFrom((int)address, (int) 4);//Request 4 bytes need 4 bytes are read
  Press_H = Wire.read();
  Press_L = Wire.read();
  byte Temp_H = Wire.read();
  byte  Temp_L = Wire.read();
  Wire.endTransmission();


  _status = (Press_H >> 6) & 0x03;
  Press_H = Press_H & 0x3f;
  P_dat = (((unsigned int)Press_H) << 8) | Press_L;
  *p_P_dat = P_dat;

  Temp_L = (Temp_L >> 5);
  T_dat = (((unsigned int)Temp_H) << 3) | Temp_L;
  *p_T_dat = T_dat;
  return (_status);



}

Posted: **Thu Aug 18, 2016 6:57 pm**

The persons code doesnt make any sense

Code: Select all

//#include <WireMW.h>
#include <Wire.h>   //I2C library 0x28H 
byte fetch_pressure(unsigned int *p_Pressure); //convert value to byte data type


#define TRUE 1
#define FALSE 0

void setup(void)
{
  Serial.begin(9600);
  Wire.begin();
  delay(500);
  Serial.println(">>>>>>>>>>>>>>>>>>>>>>>>");  // just to be sure things are working
}

void loop()
{
  byte _status;
  unsigned int P_dat;
  unsigned int T_dat;
  double PR;
  double TR;
  double V;
  double VV;
  while (1)
  {
    _status = fetch_pressure(&P_dat, &T_dat);

    switch (_status)
    {
      case 0: Serial.println("Ok ");
        break;
      case 1: Serial.println("Busy");
        break;
      case 2: Serial.println("Slate");
        break;
      default: Serial.println("Error");
        break;
    }


    PR = (double)((P_dat-819.15)/(14744.7)) ;
    PR = (PR - 0.49060678) ;
    PR = abs(PR);
     V = ((PR*13789.5144)/1.225);
    VV = (sqrt((V)));

    
    TR = (double)((T_dat*0.09770395701));
    TR = TR-50;
    
  
    
   Serial.print("raw Pressure:");
   Serial.println(P_dat);
   //Serial.println(P_dat,DEC);
   //Serial.println(P_dat,BIN);
   Serial.print("pressure psi:");
   Serial.println(PR,10);
   Serial.print(" ");
   Serial.print("raw Temp:");
   Serial.println(T_dat);
   Serial.print("temp:");
   Serial.println(TR);
   Serial.print("speed m/s :");
   Serial.println(VV,5);
  



    delay(1000);
  }
}

byte fetch_pressure(unsigned int *p_P_dat, unsigned int *p_T_dat)
{


  byte address, Press_H, Press_L, _status;
  unsigned int P_dat;
  unsigned int T_dat;

  address = 0x28;
  Wire.beginTransmission(address);
  Wire.endTransmission();
  delay(100);

  Wire.requestFrom((int)address, (int) 4);//Request 4 bytes need 4 bytes are read
  Press_H = Wire.read();
  Press_L = Wire.read();
  byte Temp_H = Wire.read();
  byte  Temp_L = Wire.read();
  Wire.endTransmission();


  _status = (Press_H >> 6) & 0x03;
  Press_H = Press_H & 0x3f;
  P_dat = (((unsigned int)Press_H) << 8) | Press_L;
  *p_P_dat = P_dat;

  Temp_L = (Temp_L >> 5);
  T_dat = (((unsigned int)Temp_H) << 3) | Temp_L;
  *p_T_dat = T_dat;
  return (_status);



}

Like where does he get these values?

Code: Select all

PR = (double)((P_dat-819.15)/(14744.7)) ;
    PR = (PR - 0.49060678) ;
    PR = abs(PR);
     V = ((PR*13789.5144)/1.225);
    VV = (sqrt((V)));

Posted: **Thu Aug 18, 2016 8:22 pm**

No idea.

When I look at openXsensor, it seems quite easy:
It reads the pressure in 2 bytes (data[0] and data[1]. You can use the code above just to get the pressure from MS4525 (in ADC steps).
It applies a mask (3FFF) because MS4525 ADC does not provide 16 bits resolution.
Then It substract 0x2000 (mid point of ADC) in order to get a positive or a negative perssure.
This is done by this line:
difPressureAdc = ( ( (data[0] << 8) + data[1] ) & 0x3FFF) - 0x2000 ; // substract in order to have a zero value

Then the pressure given in ADC steps has to be converted in PSI or Pascal knowing that 2PSI gives 80% of 16383 (ADC steps range).
Here the comment in openXsensor.
// with MS4525DO_001 a range of 2 PSI gives 80% of 16383 (= max of 14bits); 1 PSI = 6894,76 Pascal ; so 1 unit of ADC = 2/ (80% * 16383) * 6894,76)

Note: OpenXsensor adds some code in order to take care with the fact that the sensor does not always returns 0x2000 when the same pressure is applied on both entries.(differential pressure = 0). So it performs some calibration to find the offset to be applied.
OpenXsensor reads the sensors as often as possible and performs some averaging and smoothing. This is probably not required for your application.
For openXsensor it was important to measure very low pressure and to cancel noise sensor.

Posted: **Thu Aug 18, 2016 8:39 pm**

Thank you @mstrens for helping me out with this, its now clear.

Posted: **Mon Nov 14, 2016 1:55 pm**

I have built an oXs on a custom board with an MS5611 and some resistor dividers and an ACS723 to do battery monitoring. The telemetry is working for the battery monitoring but I am not getting any data for the Vspd and Alt. Having built several successful varios and also a similar system using a GY-63 and separate boards for the ACS723 and divider chains, I'm pretty sure I have the config.h file set up correctly. However in designing the board I connected both the address bits for the MS5611 to high figuring I could change the code to accommodate that address if necessary. Now that it isn't working I'm not sure where to find that line as I am not a C programmer. It is also possible I have a hardware issue on the board but I'm not sure which is the issue at this point. Can someone please enlighten me as to the correct I2C address for the pressure sensor and where it is set in the code.

Thanks
Joe

Posted: **Mon Nov 14, 2016 3:33 pm**

Look here ...

Either 0x77 or 0x76

br KH

Posted: **Mon Nov 14, 2016 6:22 pm**

Yes I eventually found it. I was searching in the I2C.cpp and I2C.h but didn't think to look right in the main ino file. I also didn't realize that the I2C address bits on the MS5611 are complementary logic so tying the CSB pins to vcc results in address 0x76 and tying to ground results in 0x77 in case anybody else got caught by surprise on this.

Thanks for your reply.

Posted: **Tue Nov 15, 2016 12:33 am**

Working now. Thanks for your help Kalle123. Now I will be able to have a hard deck small and light enough for my micro heli. This is exciting!

Posted: **Sun Dec 11, 2016 2:29 pm**

Something in the same way for the Jeti stuff:

https://www.rc-thoughts.com/

Posted: **Sun Dec 11, 2016 4:21 pm**

oXs should also support Jeti protocol.
Then all functionalities of oXs will be avaialble too (vario, GPS, airspeed, current, voltages, ...).
Code is already written but has some bugs and I have no Jeti TX/Rx at home to test it.
So, it takes much more time to test changes on oXs with a friend on the field.

openrcforums

OpenXSensor project page on google code

Re: OpenXSensor project page on google code

Re: OpenXSensor project page on google code

Re: OpenXSensor project page on google code

Re: OpenXSensor project page on google code

Re: OpenXSensor project page on google code

Re: OpenXSensor project page on google code

Re: OpenXSensor project page on google code

Re: OpenXSensor project page on google code

Re: OpenXSensor project page on google code

Re: OpenXSensor project page on google code

Re: OpenXSensor project page on google code

Re: OpenXSensor project page on google code

Re: OpenXSensor project page on google code

Re: OpenXSensor project page on google code

Re: OpenXSensor project page on google code

Re: OpenXSensor project page on google code

Re: OpenXSensor project page on google code

Re: OpenXSensor project page on google code

Re: OpenXSensor project page on google code

Re: OpenXSensor project page on google code

Re: OpenXSensor project page on google code

Re: OpenXSensor project page on google code

Re: OpenXSensor project page on google code

Re: OpenXSensor project page on google code

Re: OpenXSensor project page on google code

Re: OpenXSensor project page on google code

Re: OpenXSensor project page on google code

Re: OpenXSensor project page on google code

Re: OpenXSensor project page on google code

Re: OpenXSensor project page on google code