HSI Pulse Range Counter Display - How to manipulate in SIOC?

Hi Jack,
I have modified Var 0 start up a little to be sure that the two pulses in Var0 have been processed before we start de Control loop...

Code:

---

Var 0 Value 0
{
  &Out = 1
  &CurrentD = 0 
  &UPDOWN_Pin = 1    // count up
  CALL &Pulses 2    // correct for two OFF/ON pulse at startup
  &StartControl = DELAY 1 100 // wait a second to let two pulses above happen first
}

Var 9999 name StartControl
{
  &Control = 0
  &Control = TIMER 1 0 100  // control is called each second
}

Var 100 name Control Link SUBRUTINE
{
  L0 = &NewDistance - &CurrentD                                                                                                                                                                                             
  IF L0 <> 0
  {
    IF L0 > 0
    { 
      &UPDOWN_Pin = 1  // Ensure HSI counts UP                                                                                         
      IF L0 > 9
      {
        L0 = 9  // no more then 9 pulses per second
        &CurrentD = &CurrentD  + 9
      }
      ELSE
      {
        &CurrentD = &NewDistance
      } 
    }
    ELSE
    {                                                                                         
      &UPDOWN_Pin = 0    // We don't want to count up here!
      L0 = L0 * -1
      IF L0 > 9
      {
        L0 = 9  // no more then 9 pulses per second
        &CurrentD = &CurrentD  - 9
      }
      ELSE
      {
        &CurrentD = &NewDistance
      } 
    }
    CALL &Pulses L0                         
  }                                                                                                                   
}

Var 1, name CurrentD

Var 2, name UPDOWN_Pin, Link IOCARD_OUT, Output 21 // Count UP or DOWN selector Pin

Var 4, name Out, Link IOCARD_OUT, Output 29 // Pulse Pin

Var 5, name NewDistance, Link FSUIPC_IN, Offset $0300, Length 2  // FSUIPC VOR1 DME Input Source

Var 43 name Pulses link SUBRUTINE    // parameter is number of pulses ...
{
  &Out = 0
  &PulseUp = DELAY &Pulses 9  // 50 msec for a half pulse
}

Var 11 name PulseUp
{
  L0 = &PulseUp
  IF L0 > 0
  {
    &Out = 1
    &Finish = DELAY L0 9  // 50 msec for the other half of the pulse
 }
}

Var 12 name Finish
{
  L0 = &Finish
  IF L0 > 0
  {
    IF L0 > 1
    {
      L0 = L0 - 1
      CALL &Pulses L0  // recursive subroutine call
    }
    ELSE
    {
      &PulseUp = 0  // make responsive for another series of pulses.
      &Finish = 0      // make responsive for another series of pulses.
    }
  }
}

Var 84, name RangeFlag, Link IOCARD_OUT, Output 17 // Range Flag

---

Nico

Hi Nico,

A bit of good news, but we're still not quite there.

Firstly, I can confirm that still only 1 pulse is needed at startup instead of 2 (but I still need 2 if I'm doing the "switch test" script).

Anyway, I tuned a VOR station 1.6nm (16 pulses) away. The HSI went to 1.4, again, not bad, very close. I then tuned back to a "dead" frequency (which means "0" on the NewDistance variable) and it went perfectly back to 0.

So in other words, the HSI did not count up 16, but it did not count 16 down either (14 up and 14 down).

Then, I approached the VOR slowly. It was always off by 0.2, but it went down in perfect increments, so clearly the script is working somewhat correctly.

I then tuned a station 51.7 nm away. The HSI only went to 15, not 15.7 (157) pulses. I think this is a script fault, not hardware, as IOCPConsole reported only a few pulses sent; definitely not 517.

This was the script, same as yours, just CALL &Pulses 1, not 2:

Code:

---

Var 0 Value 0
{
  &Out = 1
  &CurrentD = 0 
  &UPDOWN_Pin = 1    // count up
  CALL &Pulses 1    // correct for two OFF/ON pulse at startup
  &StartControl = DELAY 1 100 // wait a second to let two pulses above happen first
}

Var 9999 name StartControl
{
  &Control = 0
  &Control = TIMER 1 0 100  // control is called each second
}

Var 100 name Control Link SUBRUTINE
{
  L0 = &NewDistance - &CurrentD                                                                                                                                                                                             
  IF L0 <> 0
  {
    IF L0 > 0
    { 
      &UPDOWN_Pin = 1  // Ensure HSI counts UP                                                                                         
      IF L0 > 9
      {
        L0 = 9  // no more then 9 pulses per second
        &CurrentD = &CurrentD  + 9
      }
      ELSE
      {
        &CurrentD = &NewDistance
      } 
    }
    ELSE
    {                                                                                         
      &UPDOWN_Pin = 0    // We don't want to count up here!
      L0 = L0 * -1
      IF L0 > 9
      {
        L0 = 9  // no more then 9 pulses per second
        &CurrentD = &CurrentD  - 9
      }
      ELSE
      {
        &CurrentD = &NewDistance
      } 
    }
    CALL &Pulses L0                         
  }                                                                                                                   
}

Var 1, name CurrentD

Var 2, name UPDOWN_Pin, Link IOCARD_OUT, Output 21 // Count UP or DOWN selector Pin

Var 4, name Out, Link IOCARD_OUT, Output 29 // Pulse Pin

Var 5, name NewDistance, Link FSUIPC_IN, Offset $0300, Length 2  // FSUIPC VOR1 DME Input Source

Var 43 name Pulses link SUBRUTINE    // parameter is number of pulses ...
{
  &Out = 0
  &PulseUp = DELAY &Pulses 9  // 50 msec for a half pulse
}

Var 11 name PulseUp
{
  L0 = &PulseUp
  IF L0 > 0
  {
    &Out = 1
    &Finish = DELAY L0 9  // 50 msec for the other half of the pulse
 }
}

Var 12 name Finish
{
  L0 = &Finish
  IF L0 > 0
  {
    IF L0 > 1
    {
      L0 = L0 - 1
      CALL &Pulses L0  // recursive subroutine call
    }
    ELSE
    {
      &PulseUp = 0  // make responsive for another series of pulses.
      &Finish = 0      // make responsive for another series of pulses.
    }
  }
}

Var 84, name RangeFlag, Link IOCARD_OUT, Output 17 // Range Flag

---

I also remember at the start of this thread our original script used a variable called "NoPulses". We seem to have substitued this for L0.

Also, on another note, at the end of my test, the NewDistance variable changed value 5 times but not a single pulse was sent. Weird!

Regards,

Jack;)

Hi Jack,

I have simplified the Control routine a bit. Don't think it will make a difference but it is less code.

However, I also changed the PulseUp and PulseDown delays to 5 (instead of 9) equals 50 msec for half a pulse.

Originally I used 5, don't know why you have changed that to 9???

9 pulses of 90+90 = 9 x 180 msec is more then a second delay so that will not work... These max. 9 pulses per control cycle must fit within 1 second because then the next call to the control routine starts... (do you understand?)

Here the improved script:

Code:

---

Var 0 Value 0
{
  &Out = 1
  &CurrentD = 0 
  &UPDOWN_Pin = 1    // count up
  CALL &Pulses 1    // correct for two OFF/ON pulse at startup
  &StartControl = DELAY 1 100 // wait a second to let two pulses above happen first
}

Var 9999 name StartControl
{
  &Control = 0
  &Control = TIMER 1 0 100  // control is called each second
}

Var 100 name Control Link SUBRUTINE
{
  L0 = &NewDistance - &CurrentD                                                                                                                                                                                             
  IF L0 <> 0
  {
    IF L0 > 0
    { 
      &UPDOWN_Pin = 1  // HSI counts UP                                                                                         
      IF L0 > 9
      {
        L0 = 9  // no more then 9 pulses per second
      }
      &CurrentD = &CurrentD  + L0
    }
    ELSE
    {                                                                                         
      &UPDOWN_Pin = 0  // HSI counts Down
      L0 = L0 * -1
      IF L0 > 9
      {
        L0 = 9  // no more then 9 pulses per second
      }
      &CurrentD = &CurrentD  - L0
    }
    CALL &Pulses L0                         
  }                                                                                                                   
}

Var 1, name CurrentD

Var 2, name UPDOWN_Pin, Link IOCARD_OUT, Output 21 // Count UP or DOWN selector Pin

Var 4, name Out, Link IOCARD_OUT, Output 29 // Pulse Pin

Var 5, name NewDistance, Link FSUIPC_IN, Offset $0300, Length 2  // FSUIPC VOR1 DME Input Source

Var 43 name Pulses link SUBRUTINE    // parameter is number of pulses ...
{
  &Out = 0
  &PulseUp = DELAY &Pulses 5  // 50 msec for a half pulse
}

Var 11 name PulseUp
{
  L0 = &PulseUp
  IF L0 > 0
  {
    &Out = 1
    &Finish = DELAY L0 5  // 50 msec for the other half of the pulse
 }
}

Var 12 name Finish
{
  L0 = &Finish
  IF L0 > 0
  {
    IF L0 > 1
    {
      L0 = L0 - 1
      CALL &Pulses L0  // recursive subroutine call
    }
    ELSE
    {
      &PulseUp = 0  // make responsive for another series of pulses.
      &Finish = 0      // make responsive for another series of pulses.
    }
  }
}

Var 84, name RangeFlag, Link IOCARD_OUT, Output 17 // Range Flag

---

regards,
Nico

Hi Nico,

More good news.

Firstly, the HSI counts perfect to 0000 each time at startup.

Secondly, the HSI counted perfectly 16 pulses, and then 16 back again when I reset the distance to 0.

One thing that is weird; the HSI actually counts DOWN 16 pulses from 0 (to 9984), and then down another 16 when I reset to 0. Resetting the display fixes this issue, but it is strange, especially because UPDOWN_Pin = 1 in the script.

Also, I tuned the station 51.7nm away. Unfortunately, it only got to 54 (5.4 nm) before stopping. I also noticed that it counted up in perfect blocks of 9 as you said, and 54 is 9 X 6 (so maybe 6 is a "limit" or something? I don't know, guessing here).

This is real progress though!

Regards,

Jack

Jack,
What happens if you fly over that VOR at 1.6 nm?
Nico

Hi Nico,

Sorry for my late reply.

I just conducted the following test...

- Tuned VOR 1.6 nm away.

- Went 1.7nm away

- Went 1.6, 1.5, 1.4, 1.3...

- Down to 0.5, then I went back to 0.7nm

- Then, from 0.7nm, 0.5, 0.4, 0.3...

- Down to 0. Then, I went back up to 0.7

- I then dis-tuned the VOR. (aka "0")

UP TO THIS POINT, the HSI performed absolutely brilliantly; not a single error. Then...

- Retuned VOR, which was 1.2nm away.

- HSI went to 0.6

- NewDistance increased as aI flew away. 1.3, 1.4, 1.5, 1.6, 1.7...

- The HSI stayed locked on 0.6

After studying IOCPConsole it is clear two things:

- Firstly, the HSI did not count back up correctly from 0 to 1.2

- Secondly, The NewDistance Var changed 5 times and the HSI did not receive a single pulse.

I hope these results help, but it was awesome up to 1.7 -> 0 -> 0.7 -> 0, not a single error!

Regards,

Jack

Jack,
I really have no idea at the moment. Try some more tests and try to detect a common pattern.
It looks as if the Control routine stopped...
Are you sure SIOC is still running at the end of your test (check the SIOC main window)?

regards,
Nico

HI Nico,

I can confirm that SIOC is still running.

How is it even possible for the Timer to stop? I mean, surely, if it is aleady running, then SIOC must purposely give a command to stop it. If so, why?

Regards,

Jack

Hi Jack,

Quote:

---

Originally Posted by Boeing 747 Flyer

How is it even possible for the Timer to stop?

---

If you look at the script that is very unlikely if not impossible (it is an endless timer), but it could have stopped due to a bug in the SIOC implementation...
But you confirm SIOC is still running...
That is very strange however, because then the script should sent pulses ... Are you sure the script is dead (not sending any more pulses) and not your HSI?

Regards,
Nico

Hi Nico,

I can confirm that IOCPConsole shows no pulses being sent.

IOCPConsole reports on everything SIOC does, and thus tells me exactly when it is sending the pulses. There is absolutely no reaction when the NewDistance variable changes in SIOC.

If it was a HSI fault, IOCPConsole would show pulses being sent, but the HSI display would remain dead.

Jack

Hi Jack,
Understood. So we are certain that the Pulses subroutine is no longer called because you do not see new values for PulseUp and Finish in IOCPConsole.
So we must conclude that the TIMER has stopped working ...But why?
Is it because of a bug in SIOC (I mean not in my script but in the SIOC run time)?

It would be interesting to find out exactly when the TIMER stops.
Run a few more tests with tuning VORs and flying to and over a VOR to see whether there is a "common pattern"

There is no need to change the SIOC script, it works perfectly (up and down). The only problem being that it looks as if it stops .... :-[

Regards,
Nico

HI Nico,

I shall run a few tests, seeing if it is a location (ie a specific distance that triggers it) or a timing (it happens after X minutes) problem.

Jack

Hi Nico,

I just performed some tests with some promising results.

I can 95% confirm that it is NOT the script that is faulty. Let me explain why...

Firstly, whenever the HSI did work, the Range counter performed brilliantly. I flew over, around, way past and before the VOR, the Range display kept hold of the distance perfectly all the time.

It even worked when I switched from a dead to active frequency in flight.

However, around a period of 5 minutes each time, pulses stopped being sent to the display.

The first time, I got to a distance of 10.4 miles before the display cut off.

The second time, I made sure my take-off roll was very slow. This meant that I could predict when the display would stop working (before 10.4 miles).

And, the display stopped at 9.4 miles. Just as I had thought. This means that it is definitely a TIMER issue.

Perhaps we can work out another way to repeatedly call this variable?

Regards,

Jack

Hi Jack,

Replace Var 9999 with this:

Code:

---

Var 9999 name StartControl
{
  &Control = 0
  &Control = TIMER 99999 1 100  // control is called each second
}

---

This should count longer then most flights last.

See whether this makes a difference.
regards,
Nico

Hi Nico,

That was a good idea of yours, as it has revealed a fault.

I can see the control variable going up each second by 1 in IOCPConsole. At 1202, the control variable actually just stopped, and thus no further pulses were sent.

This means that SIOC (or something) is definitely stopping the TIMER variables.

Maybe we should use an FSUIPC offset to call the control variable, something like "elapsed time" or "time in GMT" (ie something that always changes). Not ideal I know.

Regards,

Jack

Hi Jack,
Good idea, I have changed the script such that we use the seconds of FS time.
Each second our Control routine will execute.

Code:

---

Var 0 Value 0
{
  &Out = 1
  &CurrentD = 0 
  &UPDOWN_Pin = 1    // count up
  CALL &Pulses 1    // correct for two OFF/ON pulse at startup
}

Var 100 link FSUIPC_IN Length 1 Offset $023A  // seconds of FS time  (0 - 59)
{
  L0 = &NewDistance - &CurrentD                                                                                                                                                                                             
  IF L0 <> 0
  {
    IF L0 > 0
    { 
      &UPDOWN_Pin = 1  // Ensure HSI counts UP                                                                                         
      IF L0 > 9
      {
        L0 = 9  // no more then 9 pulses per second
        &CurrentD = &CurrentD  + 9
      }
      ELSE
      {
        &CurrentD = &NewDistance
      } 
    }
    ELSE
    {                                                                                         
      &UPDOWN_Pin = 0    // We don't want to count up here!
      L0 = L0 * -1
      IF L0 > 9
      {
        L0 = 9  // no more then 9 pulses per second
        &CurrentD = &CurrentD  - 9
      }
      ELSE
      {
        &CurrentD = &NewDistance
      } 
    }
    CALL &Pulses L0                         
  }                                                                                                                   
}

Var 1, name CurrentD

Var 2, name UPDOWN_Pin, Link IOCARD_OUT, Output 21 // Count UP or DOWN selector Pin

Var 4, name Out, Link IOCARD_OUT, Output 29 // Pulse Pin

Var 5, name NewDistance, Link FSUIPC_IN, Offset $0300, Length 2  // FSUIPC VOR1 DME Input Source

Var 43 name Pulses link SUBRUTINE    // parameter is number of pulses ...
{
  &Out = 0
  &PulseUp = DELAY &Pulses 5  // 50 msec for a half pulse
}

Var 11 name PulseUp
{
  L0 = &PulseUp
  IF L0 > 0
  {
    &Out = 1
    &Finish = DELAY L0 5  // 50 msec for the other half of the pulse
 }
}

Var 12 name Finish
{
  L0 = &Finish
  IF L0 > 0
  {
    IF L0 > 1
    {
      L0 = L0 - 1
      CALL &Pulses L0  // recursive subroutine call
    }
    ELSE
    {
      &PulseUp = 0  // make responsive for another series of pulses.
      &Finish = 0      // make responsive for another series of pulses.
    }
  }
}

Var 84, name RangeFlag, Link IOCARD_OUT, Output 17 // Range Flag

---

It is still hard to believe that there is a bug in TIMER implementation. I know other people that use an endless timer for motor control.
Will make a call to Spain...

regards,
Nico

Hi Nico,

That script worked great! The HSI kept track of the distance for much, much longer than the previous.

There are, however, a few problems. Firstly, the HSI was always 2 lower than FSX (eg, if the distance was 1.5m, the HSI would be 1.3m).

If FSX = 0, then the HSI = 9998.

Also, when I tuned the VOR station that was 51.7nm away, the HSI slowly sent the pulses, but stopped at 317 miles.

Regards,

Jack

Hi Jack,

That two lower problem is related to the code in Var 0. We have to fine tune that. Take also into account that Var 100 is called immediately as soon as var 0 has been executed. So we have to synchronize that.

HSI slowly sent pulses: thats'by design, it synchronizes at a pace of .9 nm per second. Maye be can sent more pulses per second? I mean why to we sent pulses of .1 second?

Your report that it stopped at 317 miles worries me more... Why is that? Has the FS time stopped? Or is there a problem with the HSI?

regards,
Nico

HI Nico,

The FS time definitely didn't stop. IOCPConsole reports that pulses stopped being sent when the HSI value read 317.

I honestly think it would help if we increased the pulse-per-second rate. Maybe 8 times as fast or something like that.

Regards,

Jack

Quote:

---

Originally Posted by Boeing 747 Flyer

I honestly think it would help if we increased the pulse-per-second rate. Maybe 8 times as fast or something like that.

---

That's quite a lot more. What does the Manual of the HSI tells you? ;-)
I mean trial and error is not the most efficient way.

Here is the code for 5 times faster, max 45 pulses per second (4.5 nm per second).

Code:

---

Var 0 Value 0
{
  &Out = 1
  &CurrentD = 0 
  &UPDOWN_Pin = 1    // count up
  CALL &Pulses 1    // correct for two OFF/ON pulse at startup
}

Var 100 link FSUIPC_IN Length 1 Offset $023A  // seconds of FS time  (0 - 59)
{
  L0 = &NewDistance - &CurrentD                                                                                                                                                                                             
  IF L0 <> 0
  {
    IF L0 > 0
    { 
      &UPDOWN_Pin = 1  // Ensure HSI counts UP                                                                                         
      IF L0 > 45
      {
        L0 = 45  // no more then 45 pulses per second
        &CurrentD = &CurrentD  + 45
      }
      ELSE
      {
        &CurrentD = &NewDistance
      } 
    }
    ELSE
    {                                                                                         
      &UPDOWN_Pin = 0    // We don't want to count up here!
      L0 = L0 * -1
      IF L0 > 45
      {
        L0 = 45  // no more then 45 pulses per second
        &CurrentD = &CurrentD  - 45
      }
      ELSE
      {
        &CurrentD = &NewDistance
      } 
    }
    CALL &Pulses L0                         
  }                                                                                                                   
}

Var 1, name CurrentD

Var 2, name UPDOWN_Pin, Link IOCARD_OUT, Output 21 // Count UP or DOWN selector Pin

Var 4, name Out, Link IOCARD_OUT, Output 29 // Pulse Pin

Var 5, name NewDistance, Link FSUIPC_IN, Offset $0300, Length 2  // FSUIPC VOR1 DME Input Source

Var 43 name Pulses link SUBRUTINE    // parameter is number of pulses ...
{
  &Out = 0
  &PulseUp = DELAY &Pulses 1  // 10 msec for a half pulse
}

Var 11 name PulseUp
{
  L0 = &PulseUp
  IF L0 > 0
  {
    &Out = 1
    &Finish = DELAY L0 1  // 10 msec for the other half of the pulse
 }
}

Var 12 name Finish
{
  L0 = &Finish
  IF L0 > 0
  {
    IF L0 > 1
    {
      L0 = L0 - 1
      CALL &Pulses L0  // recursive subroutine call
    }
    ELSE
    {
      &PulseUp = 0  // make responsive for another series of pulses.
      &Finish = 0      // make responsive for another series of pulses.
    }
  }
}

Var 84, name RangeFlag, Link IOCARD_OUT, Output 17 // Range Flag

---

regards,
Nico

Hi Nico,

Well what can I say. It is absolutely brilliant. Thanks so much!

Changing it to 45 pulses/sec has solved EVERYTHING. I mean everything!

Not a single error, it never stops being called, and it accruately reports the station be it 1.6 or 51.3nm away. It also perfectly resets to 0 even if I'm in the middle of flying towards the VOR and loose the signal.

There really is nothing left to fix IMO. A few problems may crop up, but there are none at the moment, it just works brilliantly.

Thanks so very, very much!

Regards,

Jack

Hi Jack,
CONGRATULATIONS!
Enjoy your HSI.

I will add the SIOC code of the Pulses subroutine to my howto page.

Let's close this thread now. It is very long already.

regards,
Nico

Hi Nico,

Thanks so much, but you deserve most of the thanks for your oustanding efforts and fault-finding.

Should we submit a bug report to OC regarding the SIOC issue?

That's just the glideslope and localiser motors left to do on the HSI!

Regards,

Jack

Hi Jack,
I have added a HowTo example about making a led blink a fixed number of times to my website.

Do you submit the bug report to OC?

regards,
Nico

Nico, Jack

Some interesting coding - thanks
Another application of the principles of sending pulses could be dc motor control through one of the proprietary motor control chips that act upon ttl level logic on/off signals and variable durations - could be cheaper than buying an OC card.

David

Hi David,

I had thought about using the PWM technology in the motors card, but it simply wasn't precise enough.

I myself had developed a little test circuit with a potentiometer, capacitor and PIC chip. If I put the potentiometer in "position X" for 10 seconds the HSI would count to 200, but if I did it again, it would count to 213, etc.

Nico's script makes sure we control the EXACT number of pulses sent, so that it never goes off track (even by 1).

Nico, just a small note:

I noticed one condition in which the script struggles. It is not our fault, but that of FSUIPC/FSX.

Whenever a frequency is changed, the Offset in question changes to 0 for a split second, then back up to whatever distance it is away.

This change to 0 affects our script, because the HSI tries to go to 0, and then back up to X miles. Obviously, as I said, sending two different instructions "confuses" the HSI.

I am wondering, if there is any way around this? Maybe to tell the HSI to "ignore" the temporary value of 0. Or, another idea, we make the pulse rate so fast, so that it does change to 0 and then back up to whatever extremely quickly (maybe 1000 pulses/sec, I don't know).

Anyway, just a minor problem. It is nothing to do with the script; just the offset by which it is governed.

Regards,

Jack

Hi Jack

I understand why you did not use PWM. I was thinking more about general (undemanding!!) motor control where the pulse system you have developed with Nico could easily control motors with inexpensive chips.

Regards

David

Ahhh I see, indeed!

Is there a "limit", or at least a guideline, to the maximum speed of the pulsing? I want to increase it but do not wish to damage or destroy an ouput.

Jack

Jack

Sorry, but I have not developed this thought any further. I would need to check the datasheets of the motor contoller chips to see what are the parameters. It is certainly feasible as I did a small experiment some while back using SIOC to send control pulses to the motors - though it was very hit and miss due to my crap coding at the time :)

David