I'm sorry to raise this thread again. I think I found a small bug and I need some help...

As I understand, if there's a voltage on Pin 2 (i.e. coming from a battery through a voltage divider), corresponding telemetry value is transmitted as Temp2. Also, when Pin 3 of the Attiny is short to GND, the telemetry value is transmitted as A1 instead of Temp2.

BUT: when Pin 3 of the Attiny is short to GND, the A1 telemetry value gets "overwritten" by the voltage sensor even if there's no voltage on Pin 2.

Is there a way to fix this?

I made a few of these sensor PCBs with dual inputs (both dividers are already in place). On these PCBs, the Pin3 is always connected to GND (I thought I would never need that jumper!). As soon as this sensor is connected to a receiver, A1 disappears (even if there's no battery connected to the sensor at all). This is not a big deal in general (the receiver voltage is still there as RxBatt or something similar), but it changes the default behavior and could cause some confusion...

I looked into the source code trying to fix it myself, but unfortunately my coding knowledge is far from the level required...

I'm not sure I understand the problem, other than it is working as designed!
In the Tx, we receive the SPort telemetry. From a 'X' receiver, we receive the receiver battery voltage as "RxBt", this is not A1.
For backward compatibility to 'D' receivers, the Tx makes this available as the A1 value. If you receive a real A1 value, then this is used for A1 instead of the receiver battery value.
So it is not the A1 value being overwritten, rather the A1 is no longer a copy of RxBt.

Possibly, the fix would be to change the firmware in the sensor to ignore the link input, and so send the voltage as TEMP2 all the time.

Mike.

ersky9x/er9x developer
The difficult we do immediately,
The impossible takes a little longer!

The implementation is to read the 'second' ADC input (the debug pin closest to analog connector) as a 10-bit value (0-1023). The pin is configured with an internal pullup. If the value is over 999, it is ignored. If the value is less than 1000, then the pin is changed to analog input and the read value is then sent, currently as the second temperature, having been converted to 8 bits in the same way as the original analog input.

As far as I understand, it means that if the value on Pin2 is >999, neither Temp2 nor A1 should be transmitted by the sensor.
Am I wrong?

I've made a change to the firmware for the X8R2Analog device so it doesn't "hog" the SPort bus.
This update now only sends 1 or 2 frames every 200mS instead of sending every time it is polled, which could have been a frame every 24mS.
The updated firmware (which is open source) is here: https://github.com/MikeBland/x8r-analog.

I tested using a .BAS script in ersky9x (very similar to the LUA script) and it worked OK with the X8R2Analog device attached to a S8R.

You do need an Atmel AVR/Tiny programmer to update the device. I used my AVRISP-II, but a USBASP should also work.

Mike

ersky9x/er9x developer
The difficult we do immediately,
The impossible takes a little longer!

It looks like the production version, as sold by T9 and Aloft is no longer available.
I've ported the code to an Arduino Pro Mini, 3.3V 8MHz version, so this could be used instead. It will need the SPort connector wired in, together with some resistor dividers, but otherwise it should work the same way.
Since the Pro Mini has more I/O pins, I have also added options for A3 and A4 analog inputs. Alos, with the extra flash available, the SPort physical ID may be changed using the ChangeId function in ersky9x maintenance mode or the ChangeId app available when using the ersky9x bootloader.

I'll be posting more details when I have them available.

Mike

ersky9x/er9x developer
The difficult we do immediately,
The impossible takes a little longer!