Beta 88

[old] haboustak · Post by **[old] haboustak** » June 2nd, 2005, 6:10 pm

Running Beta 88 build 8 I've got a few more state machine questions. Nothing very serious though- it seems to be tracking the diagram very well now. I tried to make sure what I've seen below happens consistently, but some things may be situation dependant. 1: No transition if MENU/BACK button pressed before workout started If you use the PC to setup a workout for the user and they press the MENU/BACK button before starting the workout the PM3 transitions to the main screen but doesn't transition to either FINISHED or READY 2: 220 second PAUSE timeout broken? I stopped rowing partway through a computer controlled workout. After about 14 seconds the PM3 detected my idling and transitioned to PAUSED. There was no transition to FINISHED though, I waited maybe 5-6 minutes. Pressing MENU/BACK causes the screen to return to the main screen, and the PM3 to transition to finished. 3: Documentation needs updates in regards to timeouts The MANUAL and FINISHED timeouts in the flowchart aren't documented on page 20. Is the MANUAL timeout the same length if the user is pasued during a JustRow as it is if the user is idling at the main screen? 4: Computer Controlled workout doesn't transition to FINISHED The PM3 doesn't transition to the FINISHED state when I row my 2K setup using the PC. The PM3 stays in IN USE mode, no transition happens. (waited about 5 mins) 5: Sending GO_READY from IDLE state doesn't update monitor The monitor stays on the User ID input screen after it transitions to READY. 6: CSAFE inconsistency in regards to IDLE and READY If you enter the MANUAL state from the IDLE state (MENU/BACK or Manual button), start a JustRow, and end the JustRow with MENU/BACK, the PM3 returns to the IDLE state. I like this functionality and it makes me wonder why exiting the FINISHED, INUSE, and PAUSED states always return to READY. Either the diagram or the functionality might need updating for consistency. 7: MENU/BACK causes PM3 reset or turn off Is there something about the MENU/BACK button I don't know? If I hold it for 4 seconds the monitor resets. If I slowly tap the button the monitor turns off after tap 4 or 5. If I hit the button two or three times for about a half second each I can make it reset. I can't make this happen on FW82. I think that's everything for now. I've been able to make it all the way through the state machine testing every element. Not much left to work on here. Mike

[old] mlyons · Post by **[old] mlyons** » June 3rd, 2005, 4:50 pm

<table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><div class='genmed'>QUOTE(haboustak @ Jun 2 2005, 05:10 PM)</div></td></tr><tr><td class='quote'>Running Beta 88 build 8 I've got a few more state machine questions. Nothing very serious though- it seems to be tracking the diagram very well now. I tried to make sure what I've seen below happens consistently, but some things may be situation dependant. 1: No transition if MENU/BACK button pressed before workout started If you use the PC to setup a workout for the user and they press the MENU/BACK button before starting the workout the PM3 transitions to the main screen but doesn't transition to either FINISHED or READY [Mark Lyons] This is fixed in the next release. It transitions to FINISHED. 2: 220 second PAUSE timeout broken? I stopped rowing partway through a computer controlled workout. After about 14 seconds the PM3 detected my idling and transitioned to PAUSED. There was no transition to FINISHED though, I waited maybe 5-6 minutes. Pressing MENU/BACK causes the screen to return to the main screen, and the PM3 to transition to finished. [Mark Lyons] This is fixed in the next release. It transitions to FINISHED and goes to the main screen. 3: Documentation needs updates in regards to timeouts The MANUAL and FINISHED timeouts in the flowchart aren't documented on page 20. Is the MANUAL timeout the same length if the user is pasued during a JustRow as it is if the user is idling at the main screen? [Mark Lyons] The block diagram states that for both the MANUAL (Note 2) and FINISHED (Note 3) states, that the PAUSED timeout is used. In MANUAL mode the timeout only applies if the user has not yet configured a workout whether on the main screen or any other screen. Once the workout is configured or configured and started the no timeout is used. In the PAUSED state, a transition to FINISHED occurs due to timeout whether the workout has started or not. 4: Computer Controlled workout doesn't transition to FINISHED The PM3 doesn't transition to the FINISHED state when I row my 2K setup using the PC. The PM3 stays in IN USE mode, no transition happens. (waited about 5 mins) [Mark Lyons] Bug confirmed and fixed in next release. 5: Sending GO_READY from IDLE state doesn't update monitor The monitor stays on the User ID input screen after it transitions to READY. [Mark Lyons] Bug confirmed. Fix made to return monitor to main screen if in IDLE or HAVEID states only. Available in next release. 6: CSAFE inconsistency in regards to IDLE and READY If you enter the MANUAL state from the IDLE state (MENU/BACK or Manual button), start a JustRow, and end the JustRow with MENU/BACK, the PM3 returns to the IDLE state. I like this functionality and it makes me wonder why exiting the FINISHED, INUSE, and PAUSED states always return to READY. Either the diagram or the functionality might need updating for consistency. [Mark Lyons] This was done by design primarily because Concept2 does not want the default state of the PM3 to be on the User ID screen. Unless the CSAFE Master is actively controlling the PM3, the PM3 should be at the main screen for "normal" use. Since the state machine transitions from the INUSE and PAUSED states to the FINISHED state when the user hits MENU/BACK, the behavior is driven totally by the FINISHED state logic. I will confirm the state machine block diagram clearly indicates the behavior. 7: MENU/BACK causes PM3 reset or turn off Is there something about the MENU/BACK button I don't know? If I hold it for 4 seconds the monitor resets. If I slowly tap the button the monitor turns off after tap 4 or 5. If I hit the button two or three times for about a half second each I can make it reset. I can't make this happen on FW82. [Mark Lyons] This feature was added after Rev 82. Now either with or without a PC connected to the PM3, hitting the MENU/BACK key 4 time within 5 seconds or holding it down continuously for > 2.0 seconds (4 samples at 0.5 seconds per sample) results in the PM3 "sleeping". If you continue to hit keys once it goes to sleep, it will wake up immediately given the impression that it "reset". I think that's everything for now. I've been able to make it all the way through the state machine testing every element. Not much left to work on here. Mike </td></tr></table> See comments interleaved above. I hope to have the next release out early next week. Just trying to tidy up a few things before putting it out there. Thanks for the valuable feedback. Mark

[old] haboustak · Post by **[old] haboustak** » July 18th, 2005, 12:26 pm

I've found another odd issue with the CSAFE state machine during my testing. Does pulling the USB cable and reconnecting it reset the state machine? At this point there is quite a bit of code in the mix, so it may be a polling issue rather than a PM3 issue, but this one seems pretty straight-forward. When I test using my app: [Ready] > [Idle] > (usb unplug) > (usb plug) > [Idle] > [Ready] The current state is polled every 250ms, the transition from Idle back to Ready took at least 3 polls. The results are the same no matter what state the PM3 is in when I pull the plug. Is there anything else on the PM3 that gets reset or altered when the USB is momentarily disconnected? It's not likely that it will happen, but someone might trip over the cords or something Mike Beta88 Build11 [edited to add] I also want to note that I upgraded to Build11 from Build8 in order to verify that this bug still exists and when I did my program no longer reported the device status correctly. Sending the GET_STATUS frame to both FW revisions: [0xF0 0xFD 0x00 0x80 0x80 0xF2] Beta88 Build8 Reples: [0xF0 0x00 0xFD 0x81 0x80 0x01 0x01 0x01 0xF2] Beta88 Build11 Replies: [0xF0 0x00 0xFD 0x81 0x81 0xF2] So Build11 is returning the generic CSAFE status packet. Which incidentally has the correct information, but doesn't appear to be the right response. Was this an intentional change to Build11?

[old] mlyons · Post by **[old] mlyons** » July 18th, 2005, 1:55 pm

Mike, Yes, the Csafe state machine is being reset to the READY state if the USB cable is unplugged. This is a design decision to return the PM3 to a "neutral" state in the CSAFE machine state so that normal PM3 functionality is available (i.e, no CSAFE specific screens, etc.). The underlying rule for CSAFE compatibility is that it does not compromise the behavior of the PM3 when not being actively exercised by a master. Relative to the response returned by the PM3 for the status command...I was informed by an experienced CSAFE development that the Build 11 behavior is more typical. This company sells a product for managing exercise equipment in health clubs and has been a resource for us relative to best practices as the CSAFE spec is not really a great document for clarifying the more detailed implementation issues. They provided the following feedback: Also, what should the response frame to the following command frame be: f1 80 <checksum> f2? f1 <status byte> 80 01 <status byte> <checksum> f2 or f1 <status byte> <checksum> f2 f1 <status byte> <checksum> f2 is what we have typically seen in other implementations - I noticed you did it the other way but as it was syntactically sensible (has the byte count) I figured it probably would not do any harm to any system. We only read the first status byte, so the rest of the frame is redundant, so I wouldn't bother sending it. If you can provide a more compelling arguement to do otherwise I'm all ears. Mark

[old] haboustak · Post by **[old] haboustak** » July 18th, 2005, 2:33 pm

<table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><div class='genmed'>QUOTE(mlyons @ Jul 18 2005, 12:55 PM)</div></td></tr><tr><td class='quote'>If you can provide a more compelling arguement to do otherwise I'm all ears. </td></tr></table> I've got no arguments to that. Just noticed that it was different after the update. It seems like a decent response to me, and I appreciate that it's more efficient, so I'll go along with it. I'm not so sure about resetting the state machine. I think that the tracking of the CSAFE state needs to be decoupled from the connection to the master. With USB it's unlikely that an intermittent connection to the master exists, but with a wireless TCP/IP network that intermittent connection becomes much more of a reality. Maybe there are a few transitions in the diagram that need to be altered if a master doesn't exist at the time of transitioning, but overall I don't see much in the PM3 that would prevent a user from normal operation. To me, 'Ready' implies that the PM3 is at the main menu and is ready to accept commands from the master. If it doesn't imply main menu to you, then perhaps it's better to think it implies that whatever the user is currently doing can be interrupted by the master. Some scenarios where that isn't the case currently: 1: Rower is mid-row and the USB disconnects I think we'll both agree that the PM3 shouldn't transition to the main menu if the USB comes unplugged. When the PM3 is plugged back in there are only 3 states that make sense based on the PM3's actual state and what commands are appropriate from the master: 'InUse/Paused', 'Manual', and 'Offline'. If we stay at 'InUse', application developers can smoothly recover from the disconnect. If we transition to 'Manual' or 'Offline' then developers will know that the user is still rowing and unable to start a workout. 2: Rower is rowing away and USB connects for the first time The PM3 should be in the 'Offline' state here, but the master is going to think it's sitting at the main menu 'Ready' for a new workout. I don't even know what a 'GoIdle' would do here, but hopefully it wouldn't put up the CSAFE Idle screen. Imagine a server that's powered on in the back room at a gym while members are working out. 3: Rower is at the Idle screen and USB disconnects This seems like one of the few good candidates for going to 'Ready'. But the current implementation doesn't change the screen to the main menu. I don't feel like the PM3 HAS to go to 'Ready' here, but it certainly can. Based on my status polling it looks like this reset of state is happening when the USB is connected rather than when it's disconnected. Which seems to go against what you're describing about leaving the CSAFE state in a known reset state when there's no connection to the master. It's more like resetting CSAFE to a known state when a connection to the master is established -- even if that goes against what the rower is currently doing. Mike [Edited to add] When I mentioned wireless TCP/IP above, I'm not talking about users connecting to RowPro via 802.11, but rather the PM3 being a member of a network via 802.11 rather than via USB.