Friday, December 30, 2011 5:57 PM
I experimented with the parallax services, but used a .Net Microframework board as a control unit.
One thing surprised me testing the serial communication, is that there is no response header defined. I see a lot of commands coming from RDS, but they folllow up quickly.
When sending a response "FFF FFF FFF FFF FFF FFF FFF FFF\r" it is sometimes picked up by the sonar!
maybe add a prefix:
"ADC FFF FFF FFF FFF FFF FFF FFF FFF\r"
Also the motor scaling and reverse polarity are unavailable. The Eddie service overwrites all custom state.
Monday, January 02, 2012 1:07 AMOwner
I am not exactly sure what you are referring to.
The Eddie service always does a send followed by a receive and expects a defined response. So when it sends and ADC command it should read all of the values that are returned. If the response is being picked up by the sonar, then some of the bytes of the previous message must still be in the PC's serial input buffer when it sends a PING command. That seems strange because the carriage return is the delimiter for a response. There is a timeout though. Are you sure that the response is being returned quickly? If you are typing it then you might be too slow.
While it might make sense for debugging to say which command you are responding to, it does not make sense to interleave commands and just adds to the protocol overhead. You will notice that some commands just respond with a carriage return. We took a minimalist approach to the protocol, but kept it as ASCII for easier debugging.
Of course, you can create your own protocol if you wish. All you need to do is replace the Parallax IO Controller service with your own service. The rest of the infrastructure should stay the same - that is the only Parallax-specific service.
Monday, January 02, 2012 6:08 PM
I made a mistake, I forgot to return the Cariage Return on "empty" commands(like GO), it is in the documentation, but is easy overlooked.
How about the motor scaling and reversing polarity?