XR8 rx telemetary sensors

[aadamson]

file attached is a CVS (import type excel or other spreadsheet file) with just the sport data shown...

Just the debug to input timing, you'll see it's a smidge (barely too quick) - but working

The full snapshot of one input to output with bubbles above the serial decode

[aadamson]

For those following along... ...

Wooo hooo... Telemetry from the Iipo *FINALLY* on the X8R...

Well, it WORKS..... More specifics later, but the debugging boards are up and functional... No changes required except for a software tweak to 2...

A million wires, but a 5v ftdi usb/serial adapter makes a really good 5V current limited supply when you need one ....it's just powering the X8R, tiny board with voltage divider is connected to the X8R's *s.port* (not s.bus port) and poof... we have Lipo volage as A2 in telemetry.



Proof via Taranis live from the X8R

[MikeB]

My ATTINY13 is fast, 412uS instead of 426. Yours is slow 437 instead of 426. The difference between them is around 6% which is over half a bit time (8uS) over the 8 bits. I changed the software timing for the data bits in the test version by about 1uS per bit.
It looks like I'm not adjusting the master clock enough, but I haven't got the timing resolution (yet). I'm measuring the duration of the start bit and first logic zero (2 bits) with the master clock divided by 8, so getting a count around 42. I think I need to measure the 6 one bits to get three times the resolution, then adjust the clock by a larger amount. It seems the factory calibration to 9.6MHz isn't very good!
I'll try to get back to this later tonight, but it may be tomorrow now.

Mike.

[aadamson]

Here is the part that I used...
http://www.mouser.com/ProductDetail/Atm ... boMeDjk%3d

*note*, it's the dual clock above version if low voltage it's will run at up to 4mhz, on higher voltage it will run at up to 10mhz. Maybe thats why?

[MikeB]

The more I think about this, if I time 8 bits at the start of the 0x7E, using timer 1 on divide by 8, then I just need to use this value on timer 1 but divide by 1, and use the timer for all timing instead of software counting. It should be much more accurate!
It will take a little longer to implement, but should then be repeatable across production.
I sometimes wonder why I copy code from something else instead of "doing it properly" myself!

Mike.

[aadamson]

The more I think about this, if I time 8 bits at the start of the 0x7E, using timer 1 on divide by 8, then I just need to use this value on timer 1 but divide by 1, and use the timer for all timing instead of software counting. It should be much more accurate!
It will take a little longer to implement, but should then be repeatable across production.
I sometimes wonder why I copy code from something else instead of "doing it properly" myself!

Mike.

hehe... I fall victim of that *all the time*... in fact, you just reminded me I need to go look at some gimbal code too that I thought of the other day ...

Let me know, this at least works so I can complete my testing of actual battery voltages... I picked up a handful of 1/8w resistors...

I'm tempted if I can figure out how to do this, where we only have one set of resistor values now, to go to SMD parts there and look at some way to do jumpers easily to bypass the first resistor if using the external module.

Also let me ask, do you think it's worth separating the grounds on the X8R side from the analog side: They are common currently and people suggest that BEC's and that may have an issue due to path to ground if a BEC or ESC fail??? Curious your thought there? And what the issue might be?

[aadamson]

Actually hooked a Lipo to the little sucker...

Mike, the jumper appears to work perfectly... with the 4S resistors and the jumper *off*, it looks like this video on 3S... voltage was remarkably accurate...

if I added the jumper, the voltage when up to 14 or 16v I can't remember for sure...

[BBvideo 425,350]http://youtu.be/IDpa2z8jXjc[/BBvideo]

[hageha]

Alan,
I once tried my experiences with 3 receivers that are burnt in connection with FRSKY voltage dividers and ESC with BEC to explain. It has happened in our club.
Unfortunately, I can do that only with the help of translators.
There were always connected while Lipo / ESC connections with banana plug and the voltage divider on the balancer connector ..
Whenever the minuspol Lipo was first isolated, and was operated throttle stick ran the entire load current, the minuspol from the balancer plug, voltage divider, receiver, BEC / ESC Ground, and motor.
The thinnest trace on fire.
That's why I'm using a ESC / BEC no ground connection at the voltage divider / receiver. I hope you can understand my description.

Hans

[aadamson]

Hans, so I think I understand the issue and your proposal is just to separate the grounds. so that the lipo connection has it's own separate from the Tiny/ADC/power supply etc... correct?

Alan

[hageha]

exactly
in the first 8 channel receivers, there was still no internal voltage divider at
A1. If you wanted to for example the 4.8 / 6 volt battery measured in a Glider, then the Grounds had to be connected
Ground is now connected via ESC/BEC.

[aadamson]

yeah, this is what I'm trying to understand... it seems that in some circumstances if the grounds aren't separated, and there is some kind of fault in either the BEC or the ESC, that this board (or the RX) will become the path for ground... So separating them is probably a good idea... I'll look at a change in a coming version... along with a size reduction.

[MikeB]

This is my design I use for a voltage divider:

Vsense.png (3.57 KiB) Viewed 14863 times

The 1K completes the circuit, but blocks any high currents.

Mike.

[MikeB]

This one uses Timer0. Measures 8 input bits with a clock/8, then uses that value to time bits with a clock/1.
Seemed to be spot on, just had to get the timing for the first half bit on receive sorted. No master clock adjustment applied. On transmit, stop bits are slightly long (by 5uS?), but the X8R recognises the data OK.

Sport.hex

5/6 Nov Midnight!

(1.94 KiB) Downloaded 357 times

Mike.

[aadamson]

Thanks Mike I'll take a look in a bit. . Appreciate all the help!

[Clivew]

Avrdude doesn't seem to support the attiny13A that I used as far as I can see?
Thanks,

Clive

[MikeB]

I'm not sure what the difference is between the '13 and the '13A, but they appear to have the same signature bytes, so just program as an ATTINY13.

Mike.

[Clivew]

Thanks Mike.
Unfortunately avrdude thinks differently, and tells me the signature bytes are wrong.
I'll maybe try a different 13A tomorrow, but have read of others having this problem.

Clive

[aadamson]

Thanks Mike.
Unfortunately avrdude thinks differently, and tells me the signature bytes are wrong.
I'll maybe try a different 13A tomorrow, but have read of others having this problem.

Clive

clive, go get the 6.0.1 version of avrdude gnu maintains it now.

[aadamson]

I'll grab you a new trace tomorrow, but this one seems like the debug ticks are slightly ahead of the serial ticks... but telemetry still works so it's close enough it's not dropping bits

[MikeB]

I've got a constant clock count offset used to adjust the first half bit time needed to allow for processing time from detection of the leading edge of the start bit. I probably need to have this adjusted based on the measured count for the 8 bits.

Clive: What signature bytes is Avrdude reporting for the '13A? The datasheet I have says 1E 90 07.

Mike.

[MikeB]

A bit more tweaking. I've reduced the offset constant to 24 (from 39). THis reduces the affect of different clock speeds.
Going from 9.9MHz to 9.3MHz only affects the start bit timing by 0.16 uS.

I've also reduced the code size a bit by using shifts and adds to do the multiply by 11, saves linking in a multiply routine.
It's probably faster as well.

Sport.hex

6 Nov, 11:35

(1.85 KiB) Downloaded 470 times

If this is OK, I'll commit the source changes.

Mike.

[aadamson]

A bit more tweaking. I've reduced the offset constant to 24 (from 39). THis reduces the affect of different clock speeds.
Going from 9.9MHz to 9.3MHz only affects the start bit timing by 0.16 uS.

I've also reduced the code size a bit by using shifts and adds to do the multiply by 11, saves linking in a multiply routine.
It's probably faster as well.

Sport.hex

If this is OK, I'll commit the source changes.

Mike.

Ok, you nailed it with that version... the debug pulses are *dead nutz* on with the rising edge of the serial clock... good stuff.

Telemetry is still functional!

Excellent work.. push away! oh, btw, you might want to remove your additional debugging info in the serial stream if you haven't already.
Alan

[Clivew]

Got mine going now, you really DO need that -B 20 in the command line to write the fuses!
Thanks for your help both,

Clive

[MikeB]

The 'tiny13 comes with the CLOCK/8 fuse active so it is only running at 1.2 MHz, hence the need to slow the programming clock.

Clive: What signature bytes is Avrdude reporting for the '13A? The datasheet I have says 1E 90 07.

I don't like "feature creep", and if this is now working I should perhaps leave it alone, BUT, a SPort sensor has a hardware ID as well as the software ID for the A2 value. I've hard coded an unused ID, but I could use 1 (or 2) of the unused pins to allow selection of form up to 4 different hardware IDs.
Alternatively, I could put an ID value into the EEPROM and use that.
Logic:
Start, read EEPROM
If EEPROM == 0xFF // Unprogrammed
Write and use default ID
else
If EEPROM is a valid ID
use it
else
write and use default ID
endif
endif

Mike.

[aadamson]

The 'tiny13 comes with the CLOCK/8 fuse active so it is only running at 1.2 MHz, hence the need to slow the programming clock.

Clive: What signature bytes is Avrdude reporting for the '13A? The datasheet I have says 1E 90 07.

I don't like "feature creep", and if this is now working I should perhaps leave it alone, BUT, a SPort sensor has a hardware ID as well as the software ID for the A2 value. I've hard coded an unused ID, but I could use 1 (or 2) of the unused pins to allow selection of form up to 4 different hardware IDs.
Alternatively, I could put an ID value into the EEPROM and use that.
Logic:
Start, read EEPROM
If EEPROM == 0xFF // Unprogrammed
Write and use default ID
else
If EEPROM is a valid ID
use it
else
write and use default ID
endif
endif

Mike.

You software guys are all alike, always wanting to *add stuff*... .

Let's do it the software way instead of the hardware way, I want to get these things done and out there... if ya know what I mean...


btw, when you are ready, I'm ready for a final revision as you'd like it ... and I'm always ready to test if needed.
Alan

[Clivew]

Mike, it was different signature every time, like 0x000105, 0xff90ff.
sometimes "target doesn't answer etc.
Putting the -B 20 (avrdude) in seems to have made it 100%

[aadamson]

add a -v and give mike the results of a verify it should tell him the ID in that listing. And I stepped from 10 (the default) to 20 on the -B... it started to work at 17, but I figured it was right on the edge there, so I just stayed at 20.

[MikeB]

I'm guessing the signature is the same, Clive just couldn't read it until he slowed the clock down.

I committed the code as was working. I've now just tested a version with the ID stored in EEPROM, all working. If the EEPROM is blank (0xFF) then the default value is stored and used. Other wise the values is validated as being between 0 and 0x1B (inclusive). If valid, it is used, otherwise the default is used.
The actual value stored in the EEPROM includes the top 3 bits which are check bits for the other 5 bits.

I'll commit this version, then I'll leave it alone.

Mike.

[aadamson]

ok... so educate me... if this is a virgin part... I flash the .hex... is that all I need to do? or do I need to flash an eeprom image too? Sorry, it's been awhile since I messed with AVR's.

I'm just trying to get to a final set of code that I can validated on a bunch of boards that people want ...how best to do that...

[MikeB]

Exactly. A brand new part will be completely erased, so the EEPROM will contain 0xFF everywhere. Also, until you set the SAVE EEPROM fuse bit, the EEPROM is erased everytime you flash the hex file.
So just flash the hex and away you go.

Mike.