Converting a Robo-Ware program to an HC-8+

[JonnyMac]

I suspect this has to do with the sloppy timing of Windows PCs -- they are not meant for precision timing (milliseconds and lower), programmers have to tweak and trick.  Micros, on the other hand, can be dead on.  In the Propeller we use a synchronized loop which guarantees the frame timing is exactly 50ms.

I've updated the program to add a constant called FUDGE.  This will allow us to "fudge" the frame timing to match the music. 

The file you sent me has 5924 frames.  At 50ms per frame this works out to a show duration of ~296 seconds but, apparently, the music is actually ~304 seconds.  If this is correct we want to fudge the frame timing by a factor of 304/296.  Since we're not using floating point we'll multiply everything by 1000.

FUDGE = (304 / 296) x 1000 = 1027 (102.7%)

As you can see, it's a pretty small variation but over the course of your long show it will stack up. I've set FUDGE for you in the attached update; here's the modified play_vixen() method that calculates the 'fudged' frame timing.  Remember, in the Propeller, timing is done in system ticks (1/80,000,000th of a second) so you can fine-tune fudge to get things perfect.  Don't do this, however, until you've got good sync on the start of the show.

Update: Fixed equation that was creating waitcnt error in 3b; version 3c is attached.

pub play_vixen(fpntr) | framehold, t, ch

'' Plays data in file defined by fpntr

  if (open_file(fpntr, "r"))                                    ' open show file
    if (readbuf(@channels, 6))                                  ' read header (3 words)
      set_rgled(GRN)

      framehold := (MS_001 * eventms) * FUDGE / 100_0           ' fudge frame timing
      framehold := (MS_001 * eventms) / 100_0 * FUDGE           ' fudge frame timing
     
      t := cnt
      repeat
        if (readbuf(@buffer, channels))                         ' read channels for one frame
          repeat ch from 0 to CH_COUNT-1
            if (CH_MASK & (1 << ch))                            ' active channel?
              servos.tx($FF)                                    '  sync byte
              servos.tx(ch)                                     '  channel
              servos.tx(buffer[ch])                             '  position

          toggle(G_LED)                                         ' show running   
          waitcnt(t += framehold)                               ' hold for frame timing                   
        else
          close_file
          set_rgled(GRN)                                        ' leave on
          quit

    else
      set_rgled(RED)

  else
    set_rgled(RED)

[JackMan]

The audio is the same length as the program, 4:56  I think the problem is just what you said, the micro is playing it at EXACTLY 20 FPS but the RoboWare/PC is playing back at a rate just a little slower than 20 FPS even though that is the setting. This is probably why I get an occassional "out of sync" routine from the RoboWare. I think there's a slight glitch somewhere in V3b, when triggered, the green LED on the HC-8+ goes out.

[JonnyMac]

Whoops, I reversed two terms in the fudged delay calculation -- it should read like this:

    framehold := (MS_001 * eventms) / 100_0 * FUDGE           ' fudge frame timing

If we do the math on a caculator it works out to:

  (80,000 x 50) / 1,000 x 1,027 = 0.05135 (51.35ms)

The reason for the problem is that 80,000 x 50 x 1,027 (in original version) was creating a number bigger than what a 32-bit long could hold and we were rolling past the waitcnt target.

[JackMan]

OK, huge oversight on my part. Not sure why I didn't check this from the start but the RoboWare is clearly not playing at a true 20 FPS. I graphed out the audio track in my music editor and the very last jaw movement should occur at exactly 4m 54s. When I entered all of the servo movements in Vixen I took them frame by frame directly from the RoboWare script. This put the very last servo movement at 4m 41.5s. I'm 12.5s short of the mark at the end of the program. If I understand your equation correctly, I need to change the FUDGE value to 104_4. Can this value be carried to another decimal because it actually needs to be 104.44%. Again, if I'm looking at this correctly, each frame actually needs to be 52.22ms.

UPDATE:  Jon, you're a freakin' genius! Good bye laptop!! At 104_4 the FUDGE constant worked like a charm, this thing is perfect spot on now. Thanks for all your help on this, it was a bit of a long road but we got 'er done! This is definitely a great example of the power and possibilities of the HC-8+.  Now that this part of my show is powered by EFX-TEK I'll have to get a video and post it in the forums. Thanks again buddy, great job!

[JonnyMac]

Jon, you're a freakin' genius!

I rule!!!  ;D

This is fantastic news.  Please do take video when you can and post it on YouTube so that others can see the work you've put into this.  And thanks for hanging in.  When John and I decided to move from the SX to the Propeller this is the kind of power I knew we could provide for our customers, and when we were developing the HC-8+ we were constantly looking for ways to make it hackable.

Congrats, Jack!

Can this value be carried to another decimal because it actually needs to be 104.44%.

Sure, if you want.  We have some leeway because there are 80,000 system clock ticks in one millisecond and we're multiplying that by 50 for the 100% frame timing.  Change FUDGE to 104_44 and the fudged frame timing calculation to:

    framehold := (MS_001 * eventms) / 100_00 * FUDGE           ' fudge frame timing

If we do the math on a caculator it works out to:

  (80,000 x 50) / 10,000 x 10,444 = 4,177,600 --> 4,177,600 / 80,000,000 = 0.05222 (52.22ms)

* 80,000,000 is the system clock frequency on which delays are based.

[livinlowe]

Wow, that is cool you got it working. Please do post a video, i am interested in seeing all your hard work paying off!

[bsnut]

Wow, that is cool you got it working. Please do post a video, i am interested in seeing all your hard work paying off!

I am glad you got it working as well.   

[JackMan]

OK guys, it's not the best quality but there's a video of this project in the completed project forums subject title "Thriller". This really doesn't do it justice as it's much better live in person with the room lights off but at least you get the idea. My laptop was the weak link in this part of my show and now that I've switched over I couldn't be happier with the performance of the HC-8+ on this, its spot on every time. By the way, this is just one part of my show, the entire show is 14 minutes.