OpenXSensor SPORT Interface

Development & General Chat for the superb openxvario project.

Moderator: rainer

OpenXSensor SPORT Interface

Postby NeilRogers » Fri Oct 18, 2013 7:25 pm

I'm trying to setup SmartPORT version Vario for taranis and X8R receiver, I downloaded the lastest version of software r193 and built hardware based on GY-63 & mini pro ATmega386.
I don't have a older rs232 Rx, but tested the vario operation by uploading oXv and the led blinks when raising the sensor.

Initially I've not connect the rx ppm and used the default setup in config.h

I've connected pin 4 to signal, gnd and raw to the sport of the X8R, with the Taranis set as one of my working FRSky Vario, I get no telemetry displays.
I've scoped the signal which sits at 0v, with data blips.

I'm not too familiar with arduino therefore I may have
missed something obvious so any pointers would be great.

I guess this is on the leading edge and not hurry, but interesting little project to start with.

As ex microcontroller assembler programmer from late 70s-80s it be good to get back into programming in the new era, looks possible to add GPS and other devices to play with

Thanks neil
NeilRogers
 
Wiltshire
United Kingdom
 
Posts: 87
Joined: Sat Jun 22, 2013 2:12 pm
Has thanked: 0 time
Been thanked: 4 times

Re: OpenXSensor SPORT Interface

Postby MikeB » Fri Oct 18, 2013 9:16 pm

The signal is serial data, but inverted so 0V is correct for an idle line.
I believe the code on the openXvario for the SPort is not currently correct, but might work. The SPort signal is a bi-directional data line, to be driven, at different times, by both the Rx and the sensor. At present, I believe there is no code to make the sensor actively drive the signal, and it relies on the internal pullup of the processor to generate a logic 1.

Without the sensor connected, you should see the Rx drive two bytes out, at 57600 baud. With the sensor, you should also see more bytes on the signal at times as the sensor responds to the Rx polling.

Mike.
User avatar
MikeB
9x Developer
 
Poole, Dorset
United Kingdom
 
Posts: 8537
Joined: Tue Dec 27, 2011 1:24 pm
Has thanked: 93 times
Been thanked: 1410 times

Re: OpenXSensor SPORT Interface

Postby NeilRogers » Fri Oct 18, 2013 9:50 pm

Thanks Mike,

I thought it may be a bit leading edge, I'll have a play around with it in oxv first analog into D6FR to check out vario operation.

Ive got a couple more minis on order so I'll play with those directly into X8R


Thanks for the guidance not far you Warminster wilts

cheers neil
NeilRogers
 
Wiltshire
United Kingdom
 
Posts: 87
Joined: Sat Jun 22, 2013 2:12 pm
Has thanked: 0 time
Been thanked: 4 times

Re: OpenXSensor SPORT Interface

Postby nicholgd » Mon Oct 28, 2013 1:40 pm

Any progress ? .I'm fairly new to this . Got very interested in Openvario and assumed that the "S port" on my X8R meant serial rs232, it was only after i had flashed the arduino and was starting to wire it up that I realized the error of my ways . "To assume is to be an ass". so a Sport version of OpenXSensor would be marvelous. Especially as FrSky seem to be dropping RS232 and going Sport.
Thanks
Geoff
User avatar
nicholgd
 
Herefordshire
United Kingdom
 
Posts: 36
Joined: Tue Sep 03, 2013 4:29 pm
Has thanked: 4 times
Been thanked: 4 times

Re: OpenXSensor SPORT Interface

Postby MikeB » Mon Oct 28, 2013 1:51 pm

I haven't had any time for this recently. Kilrah has said his works on SPort as it is.

Mike.
User avatar
MikeB
9x Developer
 
Poole, Dorset
United Kingdom
 
Posts: 8537
Joined: Tue Dec 27, 2011 1:24 pm
Has thanked: 93 times
Been thanked: 1410 times

Re: OpenXSensor SPORT Interface

Postby MikeB » Mon Oct 28, 2013 7:26 pm

I've just tried the same as you, built and loaded r193, and I get the same result, no output.
I'll see if I can work out what is wrong!
Maybe I'll just ditch the arduino software serial code and drop my, working, code from another project in!

Mike.
User avatar
MikeB
9x Developer
 
Poole, Dorset
United Kingdom
 
Posts: 8537
Joined: Tue Dec 27, 2011 1:24 pm
Has thanked: 93 times
Been thanked: 1410 times

Re: OpenXSensor SPORT Interface

Postby MikeB » Mon Oct 28, 2013 8:41 pm

Well, I've been 'playing' with the code and 'scoping the signals.
The first problem I found is the baud rate timing for 57600 baud. It was too long between receive bits. I've had to change the Rx timing in softwareSerial.cpp from 37 to 34, then the data from the Rx is recognised.
The next problem is the lack of "turning round" of the pin, it was relying on the internal pullup to drive a logic 1.
I've also added the "byte stuffing" code.
I still have one more problem. The timing of the output data is not synchronising with the polling. It should be sent shortly after receiving the polling command, but it seems rather more random than that. It may be the "read sensors()" function takes far too long for the SPort protocol. Also, it may be tahe the serial input data is being read and put into a fifo to be accessed when possible. This is NOT suitable for the SPort protocol that needs synchronising to the actual received data. Further investigation will now take place.

Mike.
User avatar
MikeB
9x Developer
 
Poole, Dorset
United Kingdom
 
Posts: 8537
Joined: Tue Dec 27, 2011 1:24 pm
Has thanked: 93 times
Been thanked: 1410 times

Re: OpenXSensor SPORT Interface

Postby MikeB » Mon Oct 28, 2013 9:23 pm

readSensors() is taking too long, around 30mS, causing the SPort code to miss its poll. The receiver then ignores the device for some time.
Indeed, readSensors() is taking up most of the processor time.
I think the code will need to be re-structured to allow the SPort protocol to work properly, the SPort code needs to be the highest priority operation, not the lowest.

Mike.
User avatar
MikeB
9x Developer
 
Poole, Dorset
United Kingdom
 
Posts: 8537
Joined: Tue Dec 27, 2011 1:24 pm
Has thanked: 93 times
Been thanked: 1410 times

Re: OpenXSensor SPORT Interface

Postby Bruneaux » Tue Oct 29, 2013 12:10 am

Mike,

Picking up on your conversation re:OpenXSensor.

I was just about to start on an Ardunio board to do the exact same thing.

I also cut my teeth in the late 70's and 80's on assembler and interrupt driven code. Did some stream capture in original IBM PC's catching 9600 baud stock market data in the background of DOS.

RE: Taranis/openTX. Are you working with code that has not been released? I am looking at the last release of "frsky_sport.cpp" and "frsky_sport.h" and I am having a problem seeing any possible way to have bi-directional data.

So I'll follow this thread and maybe I learn something!

Bruneaux
Bruneaux
 
United States
 
Posts: 96
Joined: Mon Oct 14, 2013 7:13 pm
Has thanked: 5 times
Been thanked: 0 time

Re: OpenXSensor SPORT Interface

Postby Kilrah » Tue Oct 29, 2013 3:47 am

He's talking about the openxsensor code, not openTx.

Sent from my SC-03E using Tapatalk
User avatar
Kilrah
 
Dubai
United Arab Emirates
 
Posts: 6915
Joined: Sat Feb 18, 2012 6:56 pm
Has thanked: 226 times
Been thanked: 681 times

Re: OpenXSensor SPORT Interface

Postby Bruneaux » Tue Oct 29, 2013 3:33 pm

Kilrah,

To quote the start of the thread:

NeilRogers wrote:I'm trying to setup SmartPORT version Vario for taranis and X8R receiver, I downloaded the lastest version of software r193 and built hardware based on GY-63 & mini pro ATmega386.


SPORT is Taranis and therefore OpenTX. If you can't communicate to the openXsensors then what is the point? There must be some code (openTX) to deal with the data on the openTX (Taranis specific).

A micro-controller could send data to the Taranis's code (openTX) and use the old codes (the codes that are already in existance) but the point would be to be able to ADD *new* things. So there has to be, at some point, code in the Taranis (openTX) to deal with the *new* sensors.

Further, according to FrSky (Taranis and therefore openTX) the SPORT protocol is bi-directional -through- the RF link. There may not be an implementation in openTX code but the ability is engineered in (according to FrSky/SPORT).
Image
Whether Mike and Neil are going to have the micro-controller poll the sensor and then push it down (streaming) to the Taranis/openTX or poll it from the Taranis is not yet clear to me. I will wait and see.

If you have any insights I am happy to listen/learn.

Bruneaux
Bruneaux
 
United States
 
Posts: 96
Joined: Mon Oct 14, 2013 7:13 pm
Has thanked: 5 times
Been thanked: 0 time

Re: OpenXSensor SPORT Interface

Postby MikeB » Tue Oct 29, 2013 3:48 pm

The SPort interface has ONE master device and several slave devices. The XJT is the MASTER at the Tx end and the X8R is the MASTER at the Rx end.
At each end, the MASTER device polls all possible slave devices for data. If it receives anything, it sends it across the RF link to the other end. The MASTER at the other end then forwards the data out on the SPort.
All data is transferred in short (8 byte) packets. The 8 bytes INCLUDE control and CRC overhead.

I shall be interested to see FrSky's offering for the serial port. I have a feeling the throughput will be quite low as the likely absolute maximum for the SPort is 4 bytes every 12 mS, but this is spread over all attached sensors, and even with no other sensors, a second 12mS 'slot' is needed to poll for other sensors becoming attached. In addition, there are the inbuilt packets for RSSI, Rx battery(A1) and SWR that use up some time.
It will also be interesting to see if the serial link is 'reliable' (lossless). To achieve that, some of the 4 bytes may need to be used.

Mike.
User avatar
MikeB
9x Developer
 
Poole, Dorset
United Kingdom
 
Posts: 8537
Joined: Tue Dec 27, 2011 1:24 pm
Has thanked: 93 times
Been thanked: 1410 times

Re: OpenXSensor SPORT Interface

Postby MikeB » Tue Oct 29, 2013 4:02 pm

I'm concluding the Arduino "softwareSerial.cpp" is not suited to using the same pin for both Tx and Rx. The code is quite flexible, allowing you to specify which pin to use and whether it is normal or inverted, but the transmission causes receive interrupts. The code also buffers the received data, so you lose the timing of when the data actually arrived, necessary for the SPort protocol.
For the SPort to work reliably, I propose to use my working code from elsewhere that is hard coded for a specific pin and, hopefully, sorts out the bidirectional problems.

Mike.
User avatar
MikeB
9x Developer
 
Poole, Dorset
United Kingdom
 
Posts: 8537
Joined: Tue Dec 27, 2011 1:24 pm
Has thanked: 93 times
Been thanked: 1410 times

Re: OpenXSensor SPORT Interface

Postby bertrand35 » Tue Oct 29, 2013 4:35 pm

I just see this thread. I did add the S.PORT to openXsensor during the summer (only the vario and alt fields). It worked quite well, but only with this sensor enabled, and debug disabled!

The write on the software serial is blocking all interrupts, but there is no other possibility without external components because of the inverted signal ...
bertrand35
9x Developer
 
France
 
Posts: 2697
Joined: Fri Dec 30, 2011 11:11 pm
Has thanked: 174 times
Been thanked: 394 times

Re: OpenXSensor SPORT Interface

Postby MikeB » Tue Oct 29, 2013 4:57 pm

Well, it didn't work at all on my "mini lite", it never received a single byte because the timing didn't line up with the bits.
I think the 'best' way is to monitor the receive data under interrupt, and check for a SPort poll there. If you get one, then you send the required data from within the interrupt. This way, all the sensor reading and processing can carry on much the same, only the PPM input pulse is likely to need some work.

Mike.

Edit: Just thinking, I've 'modified' my arduino install to use the same compiler I use for everything else. This 'may' have affected the timing.
User avatar
MikeB
9x Developer
 
Poole, Dorset
United Kingdom
 
Posts: 8537
Joined: Tue Dec 27, 2011 1:24 pm
Has thanked: 93 times
Been thanked: 1410 times

Re: OpenXSensor SPORT Interface

Postby Bruneaux » Tue Oct 29, 2013 5:02 pm

Mike,
Thanks. So in the absence of the XJT the Taranis is the master? Or there is no code (opentx) to be the master in Taranis (just catching the stream)? It would appear to be the latter.

Question: The X8R polls every possible code? (since I don't see any way to change the code inside the X8R). If that is the case then it makes it easier to add sensors (but there is the possibility of collision with codes). I can't hope that there is a repository of codes, can I?

If the X8R *is* polling all possible codes I could see that the SPORT (bus?) would be very busy, making any data through the RF link slow down the master(s).

There is code in the XJT (firmware downloads in FrSky web page) but is that code open source? Hmm, probably not. Not that I want to use the XJT. But if the Taranis does not pick up the master role and the XJT does, that makes it very interesting.

I find it confusing that the XJT has an S-PORT (physical plug) and the Taranis doesn't.

Is there any (available --> not proprietary) documentation on the SPORT? I've been searching (google) because FrSky does not publish the protocol (electrical and logical).

Bruneaux
Bruneaux
 
United States
 
Posts: 96
Joined: Mon Oct 14, 2013 7:13 pm
Has thanked: 5 times
Been thanked: 0 time

Re: OpenXSensor SPORT Interface

Postby MikeB » Tue Oct 29, 2013 5:35 pm

Only the XJT is a master.
The X8R (and XJT) do poll every code (28 of them), but when they get a response they seem to poll that code more frequently. So if they get a response from (say) code 1, the polling goes 0,1,2,1,3,1,4,1 etc.
FrSky have said they wish to 'control' the allocation of the codes.
No, there isn't any 'available' Sport documentation. Certain developers have been given a copy "IN CONFIDENCE".

Mike.
User avatar
MikeB
9x Developer
 
Poole, Dorset
United Kingdom
 
Posts: 8537
Joined: Tue Dec 27, 2011 1:24 pm
Has thanked: 93 times
Been thanked: 1410 times

Re: OpenXSensor SPORT Interface

Postby Bruneaux » Tue Oct 29, 2013 6:12 pm

Mike,

Ah. So the X8R does *not* pole every *possible* code (65353 if them) but poles the codes that FrSky has defined (28 defined - the ones in frysky_sport.cpp I assume). Making 'new' sensors almost impossible without modifying the Taranis (openTx's FrSky version) and re-using codes.

I had a conversation with one the people at FrSky and they indicated that they are working on new sensors to replace the older versions AND a new AirSpeed sensor. It seems that the GPS was not quite perfect so they have an improved version (SPORT version)on the way. They also indicated a SPORT version of the LiPo sensor would be ready the 1st of Oct. It appears that they are so hammered with demand for the Taranis that the sensors have been delayed. :o :roll:

I would love to see their 'road map' for the new DashBoard, etc. Especially if the XJT is the only transmitter (module) that will have SPORT ability. I have not intention to by a XJT because, according to FrSky, it can only be bound to one receiver (unlike the Taranis that can store multiple bindings with X8R's).

If anyone knows whether the XJT is, indeed, crippled that way, let me know. I hate to buy one just to prove it and through it away!

Mike, thanks for all your work on this stuff. Is there a link to the openXsensor code? I'd like to follow this work and see if I can make an I2C sensor work on the openXsensor SPORT version.

Bruneax

PS. Does the XJT (master) pole the Taranis for data? That would be very interesting but I don't see it in the code ( unless that is an alarm ).
Bruneaux
 
United States
 
Posts: 96
Joined: Mon Oct 14, 2013 7:13 pm
Has thanked: 5 times
Been thanked: 0 time

Re: OpenXSensor SPORT Interface

Postby Bruneaux » Tue Oct 29, 2013 6:23 pm

Ah, c**p! If FrSky comes out with an Airspeed sensor does that mean that the X8R's will have to be re-flashed??!?!
I guess they could re-use a code, but has repercussions too.

Bruneaux
Bruneaux
 
United States
 
Posts: 96
Joined: Mon Oct 14, 2013 7:13 pm
Has thanked: 5 times
Been thanked: 0 time

Re: OpenXSensor SPORT Interface

Postby MikeB » Tue Oct 29, 2013 6:39 pm

The SPort does indeed only have 28 possible 'physical' code for sensors, however, each sensor may return more than one type of 'logical' data, e.g. the vario returns both altitude and vertical speed. Only a few of the 'physical' code are currently defined.

The XJT module is the same as the module in the Taranis. You may be confused about the binding. The XJT supports 'receiver match'. When binding the receiver is passed a model number. If the Tx firmware supports this, using the PXX protocol to the XJT, then a bound receiver will only respond if the model number matches. I haven't tried binding more than one receiver in PPM mode, but I believe it will be possible. In any case, you can bind more than one receiver (X8R) as you can bind 2, one for channels 1-8 and the other for channels 9-16.

Look here for the openXvario code:
https://code.google.com/p/openxvario/

No, I don't think it will be necessary to change the X8R code to support more sensors. The SPort supports up to 28 physical sensors, and up to 65536 logical data items.

Mike.
User avatar
MikeB
9x Developer
 
Poole, Dorset
United Kingdom
 
Posts: 8537
Joined: Tue Dec 27, 2011 1:24 pm
Has thanked: 93 times
Been thanked: 1410 times

Re: OpenXSensor SPORT Interface

Postby Bruneaux » Tue Oct 29, 2013 11:24 pm

Mike,
Thanks again. FrSky and I must not have had a complete understanding. I was lead to believe that the XJT would not pass the 'bind'.
I still don't see a need for the XJT yet. But there might become a day that it has awesome possibilities.

Are you still thinking of re-doing the the code for the openXsensor? I'll start working with the the current openXsensor code. I believe the Arduino has an I2C library which should work perfectly for my project as long as the SPORT in the X8R and the code in the openXsensor are compatible.

Bruneaux
Bruneaux
 
United States
 
Posts: 96
Joined: Mon Oct 14, 2013 7:13 pm
Has thanked: 5 times
Been thanked: 0 time

Re: OpenXSensor SPORT Interface

Postby Kilrah » Wed Oct 30, 2013 12:29 am

What you seem to misunderstand is that the RF module in the Taranis IS an XJT, hence why we talk of it all the time.
Yes the link is bidirectional. The master polls all physical IDs at startup, and if the Taranis wanted to send uplink data it would simply respond to one of the IDs. But as mentioned no code is present in openTx for this at this point. All openTx does now is to listen to what the XJT says on the smart port and decode it.

Coordination of IDs is done by Frsky, their idea of it was that you would present them your project, and get the doc and one of the remaining 18 or so physical IDs from them. But it seems they're so overwhelmed that they never answered any of the few requests they've had so far.

Obviously many teams doing that wouldn't be practical as they would use multiple IDs for the same thing (there aren't millions of different interesting telemetry data values anyway). So coordinating it under a single project might make sense. For example getting an ID for the openxvario, then adding airspeed measurement capability to it.

Sent from my SC-03E using Tapatalk
User avatar
Kilrah
 
Dubai
United Arab Emirates
 
Posts: 6915
Joined: Sat Feb 18, 2012 6:56 pm
Has thanked: 226 times
Been thanked: 681 times

Re: OpenXSensor SPORT Interface

Postby Bruneaux » Wed Oct 30, 2013 1:36 am

Kilrah,

Ok. Physically the XJT is just an RF module. Taranis IS the master, not the XJT module. That is what I expected but my conversions with Mike had me a little confused.

So, as far as SPORT, the Taranis is a 'master' and the X8R is also a 'master'. Or, more specifically, the Taranis is *capable* of being a master but it does not yet has the computer code to do the 'master' functionality. It currently only responds to the commands from the X8R.

Would that be correct?

For my needs it probably does not matter. I am interested in getting an interface with an airspeed sensor. If the X8R polls for SPORT's then that is where I will find my answers.

When I looked at the XJT's photo it is stamped with "SPORT" and it appeared to have a physical "SPORT" receptacle. Thus I expected to be able to plug something into it and make some connections. In closer inspection the [-+S] of the SPORT is just printed there. :o :lol:


http://www.alofthobbies.com/media/catalog/product/cache/1/image/9df78eab33525d08d6e5fb8d27136e95/x/j/xjt-1.jpg

Bruneaux
Bruneaux
 
United States
 
Posts: 96
Joined: Mon Oct 14, 2013 7:13 pm
Has thanked: 5 times
Been thanked: 0 time

Re: OpenXSensor SPORT Interface

Postby Kilrah » Wed Oct 30, 2013 2:25 am

Bruneaux wrote: Taranis IS the master, not the XJT module.

So, as far as SPORT, the Taranis is a 'master' and the X8R is also a 'master'. Or, more specifically, the Taranis is *capable* of being a master but it does not yet has the computer code to do the 'master' functionality.


No!
The master on the ground is the XJT that is built in the Taranis, and is identical to an external one.
The Taranis is just a slave device on the sport bus, like a sensor is. It can listen to what goes on the bus (which it does to display data), and could talk on it for uplink by responding to a particular ID when polled by the XJT (which is not implemented, and as far as we know Frsky haven't even assigned an ID for it yet).
Currently the Taranis does NOT ever send anything on the bus, it only listens.

Sent from my SC-03E using Tapatalk
User avatar
Kilrah
 
Dubai
United Arab Emirates
 
Posts: 6915
Joined: Sat Feb 18, 2012 6:56 pm
Has thanked: 226 times
Been thanked: 681 times

Re: OpenXSensor SPORT Interface

Postby Bruneaux » Wed Oct 30, 2013 4:16 am

Kilrah,

It would be much easier to understand if the term "XJT" were not confused with the *other* "XJT".

So, there is a "bus controller" in the X8R and there is "bus controller" inside of the Taranis (or should I call it an "X9D"?).

(check-point)

The bus controller in the Taranis is on it's own PCB (or is otherwise isolated) so the micro-controller on the main PCB (where the openTX code is) really doesn't know anything about it (because it is not implemented yet).

(check-point)

EITHER:
The data from the bus is available to the micro-controller on the main PCB and it reads the data on the bus and parses out the telemetry data.
OR:
One of the bus controller's is directing the micro-controller on the main PCB to read the data and parses out the telemetry data (with no ACK).
\\ (must be the one on the X8R because the bus controller on the Taranis is not implemented yet)

Am I getting closer?

Bruneaux
Bruneaux
 
United States
 
Posts: 96
Joined: Mon Oct 14, 2013 7:13 pm
Has thanked: 5 times
Been thanked: 0 time

Re: OpenXSensor SPORT Interface

Postby Kilrah » Wed Oct 30, 2013 5:41 am

Bruneaux wrote: It would be much easier to understand if the term "XJT" were not confused with the *other* "XJT".

But as I said they are the same!
In the Taranis is a separate pcb which is the same as in an external XJT, and it's functionality is exactly the same.

Take an XJT you posted a pic of, take the board out of the case, and that's what is in the Taranis. The 5 module pins (ppm, unused, power, ground and sport) are connected to the main board, and that's it.

The Taranis mainboard (openTx) will never be a bus controller, it's the internal XJT's job.

Sent from my SC-03E using Tapatalk
User avatar
Kilrah
 
Dubai
United Arab Emirates
 
Posts: 6915
Joined: Sat Feb 18, 2012 6:56 pm
Has thanked: 226 times
Been thanked: 681 times

Re: OpenXSensor SPORT Interface

Postby Bruneaux » Wed Oct 30, 2013 6:13 am

Yesterday I actually did crack it open and looked. Nothing to really see other than there is an obvious RF board. Mostly hidden.
Bruneaux
 
United States
 
Posts: 96
Joined: Mon Oct 14, 2013 7:13 pm
Has thanked: 5 times
Been thanked: 0 time

Re: OpenXSensor SPORT Interface

Postby NeilRogers » Sun Nov 03, 2013 8:46 am

SPort Spy

This may be useful for testing operation on the Smartport, Ardiuno Mini that connects via usb and logs traffic to the Serial Monitor in the Ardiuno development environment.

Sport interface gnd -> gnd. pwr (+) -> raw sig -> rx pin (4)

Remove the Usb power and and drive from the RX

The programs a bit mickey mouse but it does the job and show the protocol on the sport.

#include <Wire.h>
#include "Arduino.h"
#include <SoftwareSerial.h>
#include "HardwareSerial.h"

#define PIN_LED 13 // The Signal LED (default=13=onboard LED)

#define rxPin 4 // rx from
#define txPin 2

// set up a new serial port
SoftwareSerial mySerial = SoftwareSerial(rxPin, txPin,true);



//****************************************************************** Setup()
void setup(){

Serial.begin(115200);
Serial.println("SPort monitor starting..");



pinMode(PIN_LED, OUTPUT); // The signal LED

// Invoke all setup methods

// define pin modes for tx, rx:
pinMode(rxPin, INPUT);
pinMode(txPin, OUTPUT);
// set the data rate for the SoftwareSerial port

mySerial.begin(57600);
mySerial.listen();




}


//************************************************************************************************** Loop()
void loop(){
static int loopcnt=0;

loopcnt+=1;


if (mySerial.available()>0){
int c = mySerial.read();
if ( c != 0 ) {
Serial.print(":");
Serial.print(c);
}
else {
Serial.println("0");
}
}
}




Typical traffic from Frsky vario
:126:57:126:131:16:0 1:9:86:0:0 143:126:228
Poll 57 Poll 83 Data from vario Poll


I could not get my SPort oxs version to reply to the poll.

Therefore my next step is to keep things simple and create a Sport Interface which handshake static information back
using 2 pins strapped together one rx the other driving tx

Then to lift vario code and produce a simple tightly coded loop with Sport interface at the top of the loop

Something like

If data changed then Send
get vario data
loop until vario data changed

For me it is easier, new to the devices and language to write something simple than to modify the existing code.
But if someone can get the existing code working so much the better.

I've not had a chance to update my taranis to the latest version, but I believe frsky added gps support which should allow further information to be displayed. I thinking add my sensor on gps alt and run frsky in the same plane and compare the log data.

I've not got a lot a time to devote on this with work, flying and plane maintenance, so someone might beat me to a working device but it is fun playing around.

All comments are of course very welcome
NeilRogers
 
Wiltshire
United Kingdom
 
Posts: 87
Joined: Sat Jun 22, 2013 2:12 pm
Has thanked: 0 time
Been thanked: 4 times

Re: OpenXSensor SPORT Interface

Postby Bruneaux » Sun Nov 03, 2013 12:46 pm

Neil,

Good to hear that you are finding some progress! And a little fun can't hurt, either.

I'm getting used to Arduino for Windows. When I copied the code (the directions to use svn is not working for me :cry: ) Arduino converted things into directories and tried to turn them in to libraries. Craziness ensued.

I was going to try emIDE instead but the Arduino f/Windows seems to make things easier.

Bruneaux
Bruneaux
 
United States
 
Posts: 96
Joined: Mon Oct 14, 2013 7:13 pm
Has thanked: 5 times
Been thanked: 0 time

Re: OpenXSensor SPORT Interface

Postby philsouche » Sun Nov 03, 2013 1:33 pm

hi Neil,

did you have other sport sensor connected ? These could be pool 0x39 and 0xe4.

I can decod respons frame from the sensor ( sensor Id 0x83) as :

0x10 = data type frame
0x0100 = data altitude Id
0x00005609 = altitude data in fact 220.25m
0x8f = CRC

I you take a look at the logs you should see vario frame with Id 0x0110.

I tried to pool my vario sensor with serial terminal software, usb-rs232 interface and diode add, but never get an answer ( I had more success with firmware upgrade).
I think maybe there is something special at startup to init it to alti/vario or firmware upgrade mode or another one.

Could you please log at startup and share ?

Thanks.

Peg@se
Last edited by philsouche on Sun Nov 03, 2013 2:45 pm, edited 1 time in total.
philsouche
 
France
 
Posts: 3
Joined: Mon Feb 18, 2013 2:11 pm
Has thanked: 0 time
Been thanked: 0 time

Next

Return to OpenXVario - an open source vario supported by the open source firmwares!!

 

Who is online

Users browsing this forum: No registered users and 1 guest

PayPal The safer, easier way to pay online
Like these forums? Like the firmwares?
Show your support by donating.
openTx manual
openTx manual
er9x manual
er9x manual
video guides
video guides
Wiki
Visit the wiki

Radio Control Gliders
and Accessories.