openrcforums

Can anyone provide any information (or links) on the S.Port protocol? I am an embedded systems engineer and I want to make a device that communicates via the S.Port with the basic idea of getting data from the plane back to the transmitter.

FrSky seem to have been saying that they were going to release info about S.Port but I haven't been able to find any so far.

Thanks in advance.

What sort of data, and how much do you want to send back?

FrSky have said they will release the SPort protocol sometime, but we don't know when.

Mike.

You can look at the ground end in OpenTX code, and the remote end in openXsensor. Rather simple.

did you already had a look at this link
https://code.google.com/p/telemetry-con ... rtProtocol

Thanks for all the replies, especially the link from mstrens which I had not found.

I only need 2 bytes (or 16-bit words) of data from a plane-mounted detector, one will be an ID and the other a signal level. It seems that the S.Port on the receiver is just polling through all the various IDs so there must be a few mS latency from data being available to it actually arriving on the ground; do you know what that latency is? Does the open community have any control of what the receiver is doing on the S.Bus?

Going to look at some microcontrollers today to see if any support inverted UART output, if not I can always cook up an inverter. Bi-directional makes it trickier but there may be a device that does it without needing FETs etc. I'll let you know what I dig up.

There is quick way to get bi-directional data transfers. Get two of these:
http://www.t9hobbysport.com/frsky-s.por ... -adc-ports
one host and one remote. (I'm not sure why Aloft haven't got them).

Just plug the remote into the receiver SPort and the host into the Tx SPort, and you have a, RS232 compatible, serial link working.

Regarding latency, it partly depends on how many devices are on the SPort. Yes, the Rx polls all IDs, but when it finds a responding device, it polls that more often. If you only have 1 device, then it polls that, then polls one other ID, then goes back to the existing device, then on to the next 'empty' ID and so on. Each poll takes 12mS. So, with just 1 device, it should get polled every 24mS.

Minor note, SPort and SBUS are not the same thing. The SPort is for telemetry, the SBUS is for servo control.

Mike.

Thanks Mike, I was aware that SPort and SBus are different. I saw a small board somewhere that connected to SPort that used an ATTiny processor, I'm looking at the datasheet for that right now.

[Edit] Looks like the ATTiny 2313 can handle inverted serial either in the USART or the USI interface, I'm now wondering if the SPort protocol is in fact Atmel USI format?

It was just you referred to S.Bus. in an earlier post and I wasn't sure you didn't mean SPort.

Was this the small board?
http://code.google.com/p/x8r-analog/

If so, this just uses 'bit banging', no hardware support.

Mike.

Your link didn't show me any pictures but the one I was thinking of is here http://www.alofthobbies.com/x8r2analog.html

Is that the same thing? I should buy one of these and check it out.

It seems to me that the ATTiny should be capable of S.Port; clearly they used the ATTiny and maybe a circuit like this one http://hackaday.com/2014/01/13/software ... -for-avrs/

I can't believe they created a new serial bus format just for S.Port, it's probably similar to I2C where the 0x7E that's described as the data open format in the links above is just the I2C address for the device, that would match the concept of the signals being "inverted serial", in I2C you can have multiple slave devices on a bus and the master can talk to each one using it's address. The data and clock lines are normally pulled up and all devices that sit on the lines use open collector pull downs to assert a '1' on the bus.

Yes, that is the board I designed, and the firmware I wrote is at my link.
SPort is a bi-directional, asynchronous serial at 57600 baud, that uses a 3-state driver.

Mike.

Mike, I didn't realize you were the one that wrote the code for this - I am humbled! Can you share any more information about the bus timing?

If this runs on +, _, and Sdata then there is no Sclk line so it can't be SPI or I2C? If not then I guess that the timing is important both ends? If serial data can be seen on the bus, then it's not microLAN.

If all requests for data start out with 0x7E followed by the address of the device, why did they include the 0x7E? Maybe it's the most significant part of a 16-bit device ID? This link https://code.google.com/p/opentx/source ... _sport.cpp shows the 'new' S.Port IDs using 16 bits (early #defines).

All devices are connected on the same bus. They all can read the data over the bus.
0x7E is a code (just a convention taken by Frsky) that identify the "start" of a polling frame send by the "master" (e.g. the Rx)
When this byte is read by a device, the device knows that it has to read the next 2 bytes that will identify the target device ID.
If the device has the same device ID, then he can send 4 bytes of data (the 4 bytes of data have to part of a frame of 8 bytes including one byte 0x10, 2 byte for the device ID, the 4 bytes of data and a check byte).
Please note that none of the 8 bytes in the frame may be 0x7E (otherwise, other listening devices could think there is a polling request.
If the device has really to send the value 0x7E, it has to replace it by 2 bytes : the first one will be 0x7D and the second will be 0x7D OR 0x20 (if I remenber well); this implies too that if the device has to send 0x7D, the device has to send 2 bytes too (0x7D + (0x7D OR 0x20). This allows the receiver to convert back the 2 bytes into one.
Please note that in those cases, the frame will contains more than 8 bytes (in theory it could be 16 bytes).

Gandalf wrote:If this runs on +, _, and Sdata then there is no Sclk line so it can't be SPI or I2C? If not then I guess that the timing is important both ends? If serial data can be seen on the bus, then it's not microLAN.

As said above it is a dead simple UART/asynchronous serial port, just that the usual TX and RX lines are multiplexed together onto a single line. The protocol is nothing standard, everything that circulates on the bus is FrSky's own design/choice.

Thanks for all the input guys, I've ordered a couple of Mike's boards from Aloft Hobbies to check them out.

Mike,

The boards arrived yesterday, they are not the same as the picture that's on Aloft's web site, it seems that the potential divider resistors have been turned into 0603 (or 0402?) SMT parts; do you have updated instructions or should I chase this down with Aloft?

Thanks in advance.

The circuit hasn't changed. Aloft are only distributing them, they won't know the details of any build changes.
There is a whole thread on it here: viewtopic.php?f=96&t=4373&hilit=x8r2analog.

This post: viewtopic.php?f=96&t=4373&p=67969&hilit ... log#p69331 may useful.

Mike.

Well I think I figured it out, the extra 2 connections at the lower right are called bypass which allows you to connect the other side of the 15k input resistor.

I have some code running on a PIC16F1823 that sends out 57,600 baud serial in the right format, I will try to get it running against the 8XR receiver this weekend. This 14-pin PIC has an onboard voltage reference and 8 channels of 12 bit A2D so we could use it to measure multiple things. Any ideas?

Like I said, the picture attached is not the same as the picture on the Aloft website which shows through hole resistors lower right.

I have reverse-engineered the schematic too.

There is some information here: http://www.rcgroups.com/forums/member.php?u=339427.

Also, I'll add a bit more on the main thread: viewtopic.php?f=96&t=4373&hilit=x8r2analog.

Mike.

Mike,

Will the boards I have have just received be loaded with the latest firmware or should I update them?

I don't actually know. I have sent a PM to the person who has been making and programming the boards to find out. He has previously said he would find a way to mark them if they have the latest but I don't know what the mark is.

If you have an easy way to connect to the 6-way holes (standard AVR 6-way programming header, then you might find it quickest to update them anyway.

A way to test is to connect them up, then while running connect the pad marked as the 2nd analog input to ground briefly. This will activate it.
You can then look on the Tx to see if you have anything on telemetry value T2.

Mike.

OK, thanks. Mine have yellow stickers on them which I suspect is the marker but there's nothing written on the sticker. I'll do the test you suggest when I run them up this weekend. I've borrowed a Tektronix scope that has a serial protocol analyzer so I'll be able to decode the data passing over the Sport.

I may get to trying some code on my PIC system too.

If anyone's interested, here's my schematic. Not sure which pad is the "2nd analog input" though. I guess I can look at the code and the data sheet.

The 2nd analog input is on port B bit 3, pin 2 of the processor.

Mike.

OK, what I've discovered so far:

The serial data on S.Port uses positive inverted logic levels, i.e 3.3v = 0 and ov = 1. i.e. 3.3v = 1 and 0v = 0 (someone told me that it was inverted - it isn't)
The X8R sends out 7E.XX aprox every 11 mS where XX is a single byte device number
The X8R polls multiple device number - it doesn't matter whether the transmitter is on or off, the values are still polled
After the X8R polls a specific device number, it waits for a response
When it gets a response, it polls the responding device every other poll and steps through the other device numbers between the responding device's number
Mike B's S.Port telemetry sensor responds to device number 1B and it replies in 4 mS
The response string is as follows:

10,PL,PH,XX,XX,XX,XX,CS

Where:
10 is the standard reply marker header
PL,PH are the parameter IDs lo byte, hi byte eg 03,F1 = 0xF103 = ADC2_ID
XXs are raw ADC data which needs to be scaled to the reference voltage
CS is a checksum calculated from all the bytes sent in the response

When 7E or 7D are data values in the return data, the return is extended by sending a 7D followed by the data ANDed with ~0x20 (1's complement of 0x20, i.e. inverted bits), the return becomes longer but the checksum is still calculated for each byte sent.

When I short pin 2 of the ATTiny to ground, Mike's board starts sending a second parameter where PL,PH is 05,00 = 0x0005 = ????
Then connecting pin 2 of the ATTiny to 3.3v gives the following response string...

10,05,00,FF,00,00,00,EA

Which indicates that FF is the data byte carrying the full scale deflection reading on the second port.

Questions if I may:
1. I can't get any data that I see on the scope/protocol analyzer to appear in the telemetry screens, I added A2 and set FSD to 13.8v in model setup but A2 reads zero all the time.
2. Where can I see what parameter 0x0005 is supposed to be in the telemetry data set?
3. Does the X8R care what parameters are sent back to it? e.g. can I create a new device that reads baro, airspeed, main battery volts and amps, and then pass these back sequentially under the 1B device number response?
4. If there are 4 data bytes in the response, why can't we liaise with the OpenTx guys to send multiple data parameters in a single response? I guess we'd have to also get FrSky on board for the X8R firmware?

The SPort signaling IS inverted. That's why we can't use a hardware UART directly.
The X8R should be polling every 12mS.
ID 0005 is temperature 2.
To question 3 - YES.
To question 4 - I believe the X8R/XJT pass the 4 data bytes through transparantly.

To question 1 - What tx firmware and revision are you using?

Mike.

More observations
Still reading through the main RCGroups thread. I tried looking at the T2 parameter (I am looking at A1,A2,T1,T2, and Batt) and I do see the data passed from the 2nd analog in (ATTiny pin 2) passed through to T2 but I get nothing at all on A2 or T1. A1 gives me the receiver battery voltage but it does that without the X8Ranalogsensor board plugged in.

I tried unplugging and reconnecting the sensor board while the X8R remained powered up but it's just the same. I can see the serial messages coming out of the sensor board but I can't see the voltage on the primary analog channel which I'm expecting to see on A2.

I've set the A2 channel range to 18.3 volts and I've also tried shorting the hi-resolution link on the sensor board 6 pin connector; I've even tried this combined with unplugging and reconnecting the sensor board; all results the same as above, no A2 value.

Is A2 where I should expect to see the reading for the battery connected to the main input - Gnd and analog in on my drawing? I am sure that the battery is the right way round and, as I say, I can see the values passed over serial in the response to FE,1B ..... e.g. 10,03,F1,7F,00,00,00,7B where 7F represents a 9v battery - it changes to 00 when I remove the battery.

Any ideas?

Mike,

You're right, the waveform IS inverted, I had a brain fart because I saw 0v that ramps up to 3v for the signal but the 3v level represents a '0' so idle low = idle at '1'. Here are some waveforms...

Sorry if people were reading mixed up captions, I was fighting with the upload captions to get them right.

Q1. I can't get any data that I see on the scope/protocol analyzer to appear in the telemetry screens, I added A2 and set FSD to 13.8v in model setup but A2 reads zero all the time.
What tx firmware and revision are you using?
I'm using a new Taranis with opentx-r2940, Date 2014-02-02, Time 17:08:51

Q2. Where can I see what parameter 0x0005 is supposed to be in the telemetry data set?
ID 0005 is temperature 2
Thanks, that matches what I see.

Q3. Does the X8R care what parameters are sent back to it? e.g. can I create a new device that reads baro, airspeed, main battery volts and amps, and then pass these back sequentially under the 1B device number response?
YES
I think you mean YES you can send whatever data you want? And NO the X8R does NOT care what parameters are sent. Right?

Q4. If there are 4 data bytes in the response, why can't we liaise with the OpenTx guys to send multiple data parameters in a single response? I guess we'd have to also get FrSky on board for the X8R firmware?
I believe the X8R/XJT pass the 4 data bytes through transparantly
So, if we could get buy in from the OpenRx guys, we could send 4 bytes in 1 parameter.

OK, so T2 appears to be working in that data gets through except I can't scale the voltage. However, I still can't see A2.

I just hooked a X8R2ANALOG board to my X8R and I am getting A2 voltage displayed (Taranis openTx 2940, own compile).
On the TELEMETRY menu, where you set the 18.3V, the received and converted value appears on the line above. I just wired the receiver battery voltage to it and I'm seeing 5.16V there.

Q3, yes I do mean NO, YES!

Mike.