ERSKYTx (was ersky9x) Questions

erskyTx runs on many radios and upgrade boards
ersky9x was a port of er9x for use on the sky9x board.
User avatar
MikeB
9x Developer
Posts: 17990
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset, UK

Re: ERSKYTx (was ersky9x) Questions

Post by MikeB »

I'm looking at the sync. processing now. Hopefully I'll have another test version in a day or so.

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

yds
Posts: 44
Joined: Fri Apr 10, 2020 6:38 pm
Country: United States
Location: Dirtee Jerzee

Re: ERSKYTx (was ersky9x) Questions

Post by yds »

8-) Thx Mike! one of the only reasons I moved from ErSkyTX back to OpenTX was those special ExpressLRS-OpenTX test builds with mixer sync baked in. now it looks like every TX OS is getting released with "CRSFshot" mixer sync :ugeek: good times! :metal:

I'm keeping ErSkyTX on the X9E -- nice to be back! I like that the model I carefully configured just the way I like it was backed up on X9D+ and restored with no issues on the X9E with the latest 223 beta. very neat that models can be moved around among radios and shared like that.

BTW, ExpressLRS devs have tested PktRate at 1000Hz as well.. there's currently no hardware, DIY or otherwise pushing the rates that high, but it's probably coming down the road.. I forget if they used those custom ExpressLRS-OpenTX builds to test that.. might have been a custom build the devs rolled just to test the PktRare..
User avatar
MikeB
9x Developer
Posts: 17990
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset, UK

Re: ERSKYTx (was ersky9x) Questions

Post by MikeB »

I've just posted a test version for the X9E that may sync. with the ELRS module.
If it is working, the offset value in the debug screen should be more stable.

Mike
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!
yds
Posts: 44
Joined: Fri Apr 10, 2020 6:38 pm
Country: United States
Location: Dirtee Jerzee

Re: ERSKYTx (was ersky9x) Questions

Post by yds »

Mike,

Flashed today's X9E_ROM.bin -- quickest way I found to flash is to plug in USB to an unpowered radio and

Code: Select all

dfu-util.exe -a 0 --dfuse-address 0x08000000 --device 0483:df11 -D X9E_ROM.bin
that takes care of flashing the bootloader and the firmware in one go.. :ugeek:

now when I select 250Hz every once in a while I see 0:249 or 1:249 the latter indicating there was one erroneous pkt received.. on the DEBUG screen I see 00000FA0 and this time offset is counting down just as fast as it was counting up before.. when offset gets down to double digits the countdown slows down, when offset rolls over to all 99999999 it counts down to about 99999800 real fast then jump down to 00000DFF and counts down from there real fast, rinse repeat.. all that while RX response looks and feels normal..

with 500Hz 0:497 0:498 fluctuates as before with an occasional 1:49X here and there.. the countdown starts at 99999999 counts down to 99999800 then jumps to 6FF and counts down to zero from there slowing down when it gets below 99 and even counting up once in a while before continuing down and rolling over, rinse repeat.. all that while RX response looks and feels normal..
User avatar
MikeB
9x Developer
Posts: 17990
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset, UK

Re: ERSKYTx (was ersky9x) Questions

Post by MikeB »

Something didn't handle a negative offset value correctly, I've just posted a test version that should fix that.

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

yds
Posts: 44
Joined: Fri Apr 10, 2020 6:38 pm
Country: United States
Location: Dirtee Jerzee

Re: ERSKYTx (was ersky9x) Questions

Post by yds »

OK, now with 500Hz selected 0:497 0:498 fluctuates same as before.. however, now the offset field seems to fluctuate too fast to read between 0000005X and 0000006X -- no more runaway counting all the way to rollover..

with 250Hz selected the bad:good ratio is now locked in at 0:250, offset fluctuates exactly as described for 500Hz, still too fast to read, but seems like about half as fast as it was ranging at 500Hz

offset seems to pause at some of the numbers for a beat then goes too fast to read again..

RX+FTDI dongle connected to the PC seems to respond fine throughout with either PktRate selected

selecting 50Hz made ExpressLRS lose connection to the RX for a long while.. when it reconnected offset went from counting up in the 000022XX range to counting down.. when the countdown finally reached the same 5X to 6X range offset started fluctuating within that same range just like it did at 250Hz and 500Hz
User avatar
MikeB
9x Developer
Posts: 17990
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset, UK

Re: ERSKYTx (was ersky9x) Questions

Post by MikeB »

Another test version posted. I probably had a boundary condition where, at 500Hz, I timed out receiving the rate and offset data, so reverted to 250Hz for sending one packet. This could explain losing 2 or 3 packets every second. I'm not sure why changing to 50Hz should lose the connection.

Mike
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!
yds
Posts: 44
Joined: Fri Apr 10, 2020 6:38 pm
Country: United States
Location: Dirtee Jerzee

Re: ERSKYTx (was ersky9x) Questions

Post by yds »

MikeB wrote: Fri Jun 18, 2021 10:53 pm Another test version posted. I probably had a boundary condition where, at 500Hz, I timed out receiving the rate and offset data, so reverted to 250Hz for sending one packet. This could explain losing 2 or 3 packets every second. I'm not sure why changing to 50Hz should lose the connection.
Mike, this version seems to bring no change in behavior whatsoever from the previous build.. going between 50Hz and 150Hz loses connection for a few beats.. going from 150Hz and up doesn't seem to lose connection.. this is probably an ExpressLRS oddity.. as I mentioned before, changing PktRate is not much of a thing.. it's never a thing mid-flight.. so long as it works at the desired PktRate.. I wouldn't bother chasing that..

500Hz still fluctuates between 0:497 and 0:498 with some dips lower than that once in a while.. never locks in at 0:500 -- that said I heard of an issue with the recently released OpenTX 2.3.12 that it's actually running ExpressLRS at 250Hz and duplicating packets when 500Hz is selected.. I haven't looked at the PR myself to say much more about that..

UPDATE: Mike, I'm sorry, my bad.. I flashed and reported on the previous build you dropped and got the same results.. the last build you asked me to test does indeed lock in at 0:500 :D offset is like reported before fluctuating in the 5X 6X range.. all the other PktRates lock in at the expected ratio.. switching in and out of 50Hz only lost connectivity once.. all other PktRate changes had no connectivity loss to the RX..
Image
spinorkit
Posts: 48
Joined: Sun Dec 31, 2017 12:21 am
Country: New Zealand

Re: ERSKYTx (was ersky9x) Questions

Post by spinorkit »

It certainly used to be the case that changing the RF packet rate caused ELRS to have to reconnect, due to the SX12xx modulation parameters having to change. They may have made the link faster at synching up again since I last checked.

I would be interested to try this latest version of ErskyTx on my 9XR Pro.
User avatar
MikeB
9x Developer
Posts: 17990
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset, UK

Re: ERSKYTx (was ersky9x) Questions

Post by MikeB »

I've posted another test version, including a build for the 9XR-PRO. I've made a very small change to the sync. timing that may get closer to 0.

Mike
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!
spinorkit
Posts: 48
Joined: Sun Dec 31, 2017 12:21 am
Country: New Zealand

Re: ERSKYTx (was ersky9x) Questions

Post by spinorkit »

Thanks Mike.
The results on my 9XR Pro with R9M and ELRS RC8 were:
Version Ersky9x-B5r223

200 Hz 0:200 0x1388 +/- ~0x50
100 Hz 0:167 0x2710 counting rapidly up to ~0x1500 and going -ve
50 Hz 0:167 0x4E20 counting rapidly up to ~0x1500 and going -ve
25 Hz 0:167 0x9C40 counting rapidly up to ~0x1500 and going -ve
yds
Posts: 44
Joined: Fri Apr 10, 2020 6:38 pm
Country: United States
Location: Dirtee Jerzee

Re: ERSKYTx (was ersky9x) Questions

Post by yds »

Mike, the latest build behaves exactly the same on the X9E -- all the PktRates lock in at the expected ratio.. offset ranges between 5X and 6X -- I saw it pause at 61 a few times, 62 and 63 as well, but there doesn't seem to be any pattern to when the pause occurs and most of the time the last digit in offset is going by too fast..

I did flash the correct bin to test this time.. ;)
User avatar
MikeB
9x Developer
Posts: 17990
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset, UK

Re: ERSKYTx (was ersky9x) Questions

Post by MikeB »

I've posted a change for the 'PRO, I missed changing a different driver file.

yds: From previous information, I think the crystals on your Tx and module differ a bit, so they don't agree what 500Hz actually is, resulting in the offset changing every 0.2 seconds, the rate at which the module sends the data.

Mike
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!
yds
Posts: 44
Joined: Fri Apr 10, 2020 6:38 pm
Country: United States
Location: Dirtee Jerzee

Re: ERSKYTx (was ersky9x) Questions

Post by yds »

MikeB wrote: Sat Jun 19, 2021 2:35 pmyds: From previous information, I think the crystals on your Tx and module differ a bit, so they don't agree what 500Hz actually is, resulting in the offset changing every 0.2 seconds, the rate at which the module sends the data.
that makes sense.. offset seems to fluctuate within the same range of values somewhere between 0x50 and 0x6F regardless if I select 500Hz or 250Hz or even 50Hz

would it help if I logged the DEBUG data for you to see?
User avatar
MikeB
9x Developer
Posts: 17990
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset, UK

Re: ERSKYTx (was ersky9x) Questions

Post by MikeB »

I'll need to add something to be able to log the debug data to a file, I may look into doing that.
The value you are seeing is in uS, so between 80 and 121. My method of synchronising is to adjust my timing by 20uS if the offset is greater than 100 (or less then -100) and by 6uS otherwise. It seems that the module is changing by more than 6uS relative to the Tx every 0.2 seconds. So once the offset is above 100, my change of 20 brings it down, but then my change of 6 is not enough to keep it coming down and it goes back above 100.

This difference is more than 30 ppm (parts per million).
Maybe I could increase the smaller change to 10.

Mike

Edit: Change done and posted, this one uses 30uS if above 100 and 10uS if below.
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!
yds
Posts: 44
Joined: Fri Apr 10, 2020 6:38 pm
Country: United States
Location: Dirtee Jerzee

Re: ERSKYTx (was ersky9x) Questions

Post by yds »

Mike, your latest build makes no difference that I can see with a naked eye.. tested at both 500Hz and 250Hz, the offset still fluctuates in the same range of 0x50 to 0x6F

here's what one of the ELRS devs had to say when I mentioned your last message in Discord:
JamesK wrote:xo on the tx module should be 10ppm. You'd need to check what the handset is using, but then you could calculate if the observed difference is in the realms of "likely" or not.
hmm, ok, so a quick check of xo suggests up to 50ppm is pretty common, but you get the drift (ta-ding!)
User avatar
MikeB
9x Developer
Posts: 17990
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset, UK

Re: ERSKYTx (was ersky9x) Questions

Post by MikeB »

Try the latest one I've just posted. It tries to detect the amount of drift and cancel that out.

Mike
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!
User avatar
MikeB
9x Developer
Posts: 17990
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset, UK

Re: ERSKYTx (was ersky9x) Questions

Post by MikeB »

I think I made a mistake so there is now another one to test!

Mike
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!
yds
Posts: 44
Joined: Fri Apr 10, 2020 6:38 pm
Country: United States
Location: Dirtee Jerzee

Re: ERSKYTx (was ersky9x) Questions

Post by yds »

Mike, I tested both of them.

the first one was ranging between 0x1F and FFFFFFFX not sure what the last digit was.. but it never went above 0x1F at 500Hz or 250Hz

the second build, with 250Hz selected, at first looked like it was scanning up and down much too fast to read anything.. into 3 digits this time, somewhere between 0x5FF and FFFFFFFX ?? but then it settled and locked in at offset 0x565 -- I couldn't reproduce it locking in at any offset after that one time.. 500Hz and 250Hz both also throw more bad packets now.. when the bad packet's do happen they add up to the selected PktRate.. e.g. 1:499, 3:497, 2:498

seems like the prior to last build might have been more dialed in..
the offset was going up and down +/- no more than 20 uS
on the last build the offset goes into 100s of uS and fluctuates way too fast to read anything..
User avatar
MikeB
9x Developer
Posts: 17990
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset, UK

Re: ERSKYTx (was ersky9x) Questions

Post by MikeB »

Not sure why the last but one worked well, but the one before that didn't.
Anyway, I've posted a new test version that should do the same as the one that worked, but with some extra code that didn't actuall add anything removed.
Please try the one posted at 19-Jun-2021 21:46.

Mike
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!
yds
Posts: 44
Joined: Fri Apr 10, 2020 6:38 pm
Country: United States
Location: Dirtee Jerzee

Re: ERSKYTx (was ersky9x) Questions

Post by yds »

MikeB wrote: Sat Jun 19, 2021 8:49 pmI've posted a new test version that should do the same as the one that worked, but with some extra code that didn't actuall add anything removed.
even better! now both 500Hz and 250Hz offset is mostly in the single digits with occasionally going above 0x10 and sometimes dipping below FFFFFFFF

still racing too fast to read, but now the offset seems to spend most of its life in single digits..
User avatar
MikeB
9x Developer
Posts: 17990
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset, UK

Re: ERSKYTx (was ersky9x) Questions

Post by MikeB »

OK, I'm happy with that. Within 10uS or so of zero is good enough, particularly when ELRS is giving 400uS "headroom", and the drift of at least 6uS every 200mS.

Mike
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!
yds
Posts: 44
Joined: Fri Apr 10, 2020 6:38 pm
Country: United States
Location: Dirtee Jerzee

Re: ERSKYTx (was ersky9x) Questions

Post by yds »

MikeB wrote: Sat Jun 19, 2021 9:17 pmOK, I'm happy with that. Within 10uS or so of zero is good enough, particularly when ELRS is giving 400uS "headroom", and the drift of at least 6uS every 200mS.
cool :metal: does this mean "CRSFshot" mixer sync is fully implemented now?
spinorkit
Posts: 48
Joined: Sun Dec 31, 2017 12:21 am
Country: New Zealand

Re: ERSKYTx (was ersky9x) Questions

Post by spinorkit »

Hi Mike,
On my 9XR Pro the latest version gives:
ersky9x-B5r223 19.06.2021 16:41:00
200 Hz 0:395 1388 +/- ~0xf
100 Hz 0:100 0x2710 +/- ~0xf
50 Hz 0:50 0x4E20 counting from ~0x1000 multiple times then eventually +/- ~0xf
25 Hz 0:250 0x9C40 +/- ~0xf

So 100 Hz and 50 Hz look good, although 50 Hz seemed to take ~ 1 min for the synch offset to settle down.
spinorkit
Posts: 48
Joined: Sun Dec 31, 2017 12:21 am
Country: New Zealand

Re: ERSKYTx (was ersky9x) Questions

Post by spinorkit »

Hi Mike,
I would think, given how old some of the Txs and modules out there are, it might be common to have frequency offsets of >100 parts per million so a phase locked loop with a little integral gain might help, and is probably what you have implemented already.

I use software phase locked loops in my work quite often, so on the off-chance it contains any useful ideas, this is a recent, quite robust one I wrote that locks the processor clock of xtal-less SAMD series processors, which have a Digitally Controlled Oscillator (DCO), to the 1kHz USB Start of Frame signal so that multiple USB transducers using these chips stay in synch for the purposes of data recording.

The "phase detector" reads the Cortex sys timer in the USB Start of Frame interrupt to generate a signed "phase" equivalent to the sync offset.

The loop uses low-pass filtered Proportional (lead feedback) with Integral (lag) feedback combined with clipped unfiltered proportional feedback ( to improve short-term stability and tracking).
The integral gain and proportional gain need adjusting by factors if 2 to ensure the lock is achieved in a reasonable time frame. If it oscillates, reduce the integral gain or increase the proportional gain and reduce the kLeadPhaseTC.

Of course in ErskyTx you are controlling the period of the PWM timer not its frequency, but that just means controlling a delta period subtracted from the nominal period, i.e. 1/(1+x) approximately equals (1-x) for x << 1.

Code: Select all

volatile int16_t gLastFrameNumber = 0;
volatile int32_t gPrevFrameTick = -1;

volatile int gLastDCOControlVal = 0;

volatile bool gUSBBPinState = false;

const int kHighSpeedTimerTicksPerus = 4;
const int kHighSpeedTimerTicksPerUSBFrame = 1000*kHighSpeedTimerTicksPerus;

const int kOneOverLeadGainus = 1;   // 1/proportional gain

#if defined(__SAMD51__)
   const int kOneOverLagGainus = 4096; // 1/integral gain
   const int kOneOverClippedLeadGainus = 4; 
#else
   const int kOneOverLagGainus = 2048; // 1/integral gain
   const int kOneOverClippedLeadGainus = 1; 
#endif
const int kFixedPointScaling = kOneOverLagGainus*kHighSpeedTimerTicksPerus;

//Integrator for integral feedback to remove DC error
volatile int32_t sPSDPhaseAccum = 0;

//First order LPF for lead (proportional) feedback
volatile int32_t gLeadPhaseAccum = 0;
const int kLeadPhaseTC = 16;

volatile int32_t gLastUSBSOFTimeus = 0;

extern "C"
{

void USBHandlerHook(void)
{
if(USB->DEVICE.INTFLAG.bit.SOF) //Start of USB Frame interrupt
   {
   gLastUSBSOFTimeus = micros();
   digitalWrite(1, gUSBBPinState = !gUSBBPinState );

   //Measure phase using Cortex cpu timer. Convert to 0.25 us ticks using a runtime multiply and compile time divides for speed.
   int32_t frameTick = ((SysTick->LOAD  - SysTick->VAL)*(kHighSpeedTimerTicksPerus*1024*1024/(VARIANT_MCK/1000000)))>>20;
   if(gState == kWaitingForUSBSOF)
      {
      adcTimer.enable(true);
      gState = kStartingSampling;
      }
   //frameus in range [0, 1000)
   //usbd.frameNumber();
   gLastFrameNumber = USB->DEVICE.FNUM.bit.FNUM;
   //if(gPrevFrameTick >= 0)
      {
      int phase = frameTick;
      //phase needs to be bipolar, so wrap values above kHighSpeedTimerTicksPerUSBFrame/2 to be -ve. We want to lock with frameHSTick near 0.
      if(phase >= kHighSpeedTimerTicksPerUSBFrame/2)
         phase -= kHighSpeedTimerTicksPerUSBFrame;

      //First order LPF for lead (proportional) feedback (LPF to reduce the effects of phase detector noise)
      gLeadPhaseAccum += phase;
      int leadPhase = gLeadPhaseAccum/kLeadPhaseTC;
      gLeadPhaseAccum -= leadPhase;

      //Unfiltered lead feedback clipped to +/- 1 to reduce the effects of phase detector noise without adding delay
      int signOfPhase = 0;
      if(phase > 0)
         signOfPhase = 1;
      else if(phase < 0)
        signOfPhase = -1;

      //Calculate the filtered error signal
      int32_t filterOut = (signOfPhase*kFixedPointScaling/kOneOverClippedLeadGainus + 
         leadPhase*kFixedPointScaling/(kOneOverLeadGainus*kHighSpeedTimerTicksPerus) + 
         sPSDPhaseAccum)/kFixedPointScaling;
      sPSDPhaseAccum += phase; //integrate the phase to get lag (integral, 2nd order) feedback

      //Clip to limits of DCO
      if(filterOut > kDFLLFineMax)
         filterOut = kDFLLFineMax;
      else if(filterOut < kDFLLFineMin)
         filterOut = kDFLLFineMin;

      int32_t newDCOControlVal = kDFLLFineMax - filterOut;

      gLastDCOControlVal = newDCOControlVal;

      //Set DCO control value
      #ifdef PHASE_LOCK_TO_USB_SOF
      #if defined(__SAMD51__)
      OSCCTRL->DFLLVAL.bit.FINE = newDCOControlVal & 0xff;
      #else
      //SAMD21 has 10 bit fine DCO control
      SYSCTRL->DFLLVAL.bit.FINE = newDCOControlVal & 0x3ff;
      #endif
      #endif
      }
   gPrevFrameTick = frameTick;

   }
UDD_Handler();
}
User avatar
MikeB
9x Developer
Posts: 17990
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset, UK

Re: ERSKYTx (was ersky9x) Questions

Post by MikeB »

I've just posted a test version for the 'PRO. Because the 'PRO uses a different low level driver, in a separate file, I'm not certain a had exactly the same functionality in both drivers, so I now know exactly what I have in this one.

I'm keeping the method of synchronising fairly simple, and not looking to sync. quickly, a few seconds doesn't really matter, and being within around +/-10uS is also good enough.

I'll note your code however, thank you.

Mike
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!
spinorkit
Posts: 48
Joined: Sun Dec 31, 2017 12:21 am
Country: New Zealand

Re: ERSKYTx (was ersky9x) Questions

Post by spinorkit »

Thanks Mike,
My results with the latest 'PRO version are:
ersky9x-B5r223 20.06.2021 10:24:23
200 Hz 0:395 1388 +/- < 0xf
100 Hz 0:100 0x2710 +/- < 0xf
50 Hz 0:50 0x4E20 counting down then eventually +/- < 0xf
25 Hz 0:250 0x9C40 +/- < 0xf

So 100 Hz and 50 Hz look good but perhaps 25 Hz is locking to a harmonic?
I don't use 25 Hz, mainly 50 or 100 Hz.
200 Hz used to show 0:200 in version B4 but I don't understand why the sync offset now looks good when ELRS reckons its is getting 395 packets/s?
User avatar
MikeB
9x Developer
Posts: 17990
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset, UK

Re: ERSKYTx (was ersky9x) Questions

Post by MikeB »

Not sure about 200Hz, I'll look at the code again.
The 25Hz is too slow at present. My timer uses a 0.5uS resolution and I alternate between 2.5mS (5000 period) and "the rest". In the case of 25Hz "the rest" is 37.5mS giving a period of 75000, which is too large for a 16 bit timer, so I default to 4mS (250Hz).

I'll see if I can sort this, but I currently rely on the 5000 count for the 2.5mS for running the mixer at the right time.

Mike
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!
User avatar
MikeB
9x Developer
Posts: 17990
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset, UK

Re: ERSKYTx (was ersky9x) Questions

Post by MikeB »

New test version posted. I've done a small change that might sort the 200Hz and I've picked the request for 25Hz and I am sending at 50Hz for now.

Mike
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!
spinorkit
Posts: 48
Joined: Sun Dec 31, 2017 12:21 am
Country: New Zealand

Re: ERSKYTx (was ersky9x) Questions

Post by spinorkit »

Thanks Mike,
that version looks pretty good:
ersky9x-B5r223 20.06.2021 20:34:28
200 Hz 0:200 0x1388 ~0x50 to ~0x60
100 Hz 0:100 0x2710 +/- < 0xf
50 Hz 0:50 0x4E20 counting down then eventually +/- < 0xf
25 Hz 0:50 0x9C40 +/- counting down then eventually +/- < 0xf

I'm not sure why the 200 Hz would have that offset when the others don't, but not important, especially if you understand why!

Post Reply

Return to “erskyTx (was ersky9x)”