Firmware 976

[old] haboustak · Post by **[old] haboustak** » April 7th, 2005, 11:40 am

I've been fairly busy the past few weeks with lot's of work and spring cleaning/yardwork, so I haven't had much chance to pull the PM3 and run some tests on the new firmware. I do have a few minor comments on Rev 976 based on the time I've had available so far. The first is that sending a SET_PROGRAM command from the Ready state causes the PM3 to transition from READY to OFFLINE. I think that this was probably introduced by the Just Row/Manual Workout fixes. Other than that the state machine has been working great in my early tests. I think that I may have seen some weirdness finishing a workout dealing with the new timeout values, but I haven't had a chance to figure it all out. The fancy new state diagram is missing its transition from HaveID to InUse -- but in my eyes it's a huge step in the right direction. I'm going to try and get my state machine test application into releaseable form and ported from OS X to Windows in hopes that other people might use it to test for bugs. The second is merely a comment on the units of GET_WORKTIME / GET_WORKDISTANCE. Now that these commands have been fixed I'd imagine that any code using them would need to be changed. I was getting understandably weird results from my test code because "technically" the units are now decimeters and centiseconds in order to accomodate what's called an increase in resolution. Does anyone know how the fraction byte works, is the value in 1/255ths meter/second? floor(GET_WORKTIME/100) + (Fraction Byte / 255) = WORKTIME +/- .004 I really hope that I can find some time to experiment with the new firmware. I'm going to cross my fingers for some rain to keep me indoors this weekend! Mike

[old] mlyons · Post by **[old] mlyons** » April 12th, 2005, 11:49 am

Mike, Thanks for the valuable feedback. Let me address several of your comments/observations. The behavior of the CSAFE state machine will be modified to only transition from READY to OFFLINE in the event that rowing actually begins. Similarly, in the IDLE state if a user begins to row without entering the requested User ID, the state machine will be modified to transition to the MANUAL based on rowing activity. I've updated the state diagram in the document to include the missing line from HaveID to InUse. The only difference in the GET_WORKTIME command in the new release is that previously it was defined to return the WORKTIME with resolution of 0.01 seconds, but was only returning the integer seconds with the 0.01 second resolution. The change that was made in the new release kept the same behavior (e.g., first 4 bytes is time in integer seconds with 0.01 second resolution) but added a fifth byte which is the non-integer portion of the time with 0.01 second resolution. Therefore, no different handling of the GET_WORKTIME command between last release and this release should be necessary other than an extra byte of information is provided. If you refer to pg. 41 of the Communications Interface Definition document, an example of the new command is provided. The same holds for the distance command. Mark

[old] haboustak · Post by **[old] haboustak** » April 12th, 2005, 4:13 pm

Mark, Thanks for fixing things! I appreciate the steps forward the SDK has made, and I hope to be a long-time contributor. I think that I follow what you've said in regards to GET_WORKTIME and GET_WORKDISTANCE. The first four bytes represent floor(GET_WORKTIME) and the fifth byte, which is the only 'new' byte, represets GET_WORKTIME - floor(GET_WORKTIME). The example you pointed out on pg 41 of the manual agrees with what I've seen in my own code. The response to GET_WORKTIME (2:30.85) is: 0x98 0x3A 0x00 0x00 0x55 This is not 150 seconds, 85 centiseconds. 0x00003A98 is 15,000, which is the value of GET_WORKTIME in centiseconds (or base-1000), and not the integer portion of a floating-point time. It may, however, be an integer that's arbitrarily shifted 2 digits, as I can't say I've ever tested or seen 14,999, vs 14,900 as the next step. I can really only speak for my code that was using GET_WORKDISTANCE and was NOT using the PM3 SDK. Before, at the start of my 2K workout, the 4-bytes of GET_WORKDISTANCE would return: 0xD0 0x07 0x00 0x00, which is 2,000. Now it returns 20,000 decimeters and I have to divide by 10 to get the proper distance. I don't have a PM3 in front of me, and so I can't say whether it steps in base-100 integers or not. It definitely required a change in my code, but again - I am a special case that I'm not using the PM3 SDK (yet). Hopefully I'll have something more helpful in the coming days. Mike [EDIT] As I check back to pg 39 of the SDK v1.2 (Rev 007 of the PDF) I can see that the GET_WORKTIME example used to return: 0xED 0x3A 0x00 0x00 Which is 15,085 seconds. So maybe I am misundertanding how the the first four bytes was and is now working. I read your post and it seems that when you say "with 0.01 second resolution" that we really should be expeciting centiseconds in the first four bytes. (or 15,085cs == 150.85s) I'm am certain that I had the correct WORK_DISTANCE without dividing by 10 in the previous revision. I'll run some tests from here and see what differences I find in the two revisions of the firmware.

[old] mlyons · Post by **[old] mlyons** » April 12th, 2005, 4:29 pm

Mike, Both the worktime and workdistance are provided as the integer portion (your terminology is FLOOR) represented in their respective resolutions, 0.01 seconds and 0.1 m. Therefore, the worktime of 0x3A98 is 15000 * 0.01 seconds/LSB = 150.00 seconds. Similarly, the workdistance of 0x07D0 is 20000 * 0.1 m/LSB = 2000.0 meters. If you refer to Table 3, the specifics of these two commands are defined including the resolution for each. Mark

[old] John 'SugarBoy' Foy · Post by **[old] John 'SugarBoy' Foy** » May 21st, 2005, 5:01 pm