mchelper 2.0 on MacBook Pro + Serial Read Issues

I've been attempting to hook up a serial GPS device to my Make Controller and read in data using OSC commands from mchelper prior to interfacing it with AS3 (as an aside, it's really nice to be able to do this with the new version of mchelper). While I've been able to write to the serial port successfully using both /serial/char and /serial/block, reading from it always yields some sort of disaster. Initially I thought that perhaps the level shifter was not functioning properly. However, checking it out with a multimeter I found it to be otherwise. Then, I verified that the level shifter was indeed reversing TX/RX as it does, and it was indeed. I then connected the GPS device directly to my computer using a RS232/USB converter and was successfully able to read the serial data, so that eliminated the actual GPS receiver as the problem. Checking on those things seemed to eliminate what I figured were circuit or hardware problems, which left only the Make Controller and mchelper as the issue. So here are a couple use cases where I run into issues: Attempting to set the baud rate using /serial/baud 4800 is apparently successful, until I type in /serial/baud to return the value and it is inexplicably set to 4828!? Any other number that I pick at random results in it being set correctly. I have no idea what to make of this behavior. As an additional problem, when I type in /serial/readable I receive a value of 1048760. If I then enter /serial/block to attempt to read that data, mchelper crashes [Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000000)]. If I then try /serial/block 128 (or any other int), then I get a /serial/error Bad Data response. Is there something obvious that I am doing incorrectly, or is this really some bugginess in mchelper?

Oooooh, I know what that is. That's definitely some bugginess in mchelper I had not tested this (since the /serial/block message is about the only one in the system that does it) but mchelper, as it's currently set up doesn't deal with OSC blobs properly, which is what the /serial/block message sends. We'll need to create a way to designate that a certain message should be encoded as a blob, which will probably be something like square brackets [] around a message. I'm not sure what the strange readback of the baud rate might be off the top of my head, but I'll have a look. Thanks for the report.

Thanks for looking into the issue. Drop me a comment at http://phy5ics.com/blog/2007/10/02/make-controller-mchelper-20-and-serial-subsytem-issues/ if you need some assistance with testing after you make any changes to mchelper.

Previously Liam Staskawicz wrote:

Oooooh, I know what that is. That's definitely some bugginess in mchelper

I had not tested this (since the /serial/block message is about the only one in the system that does it) but mchelper, as it's currently set up doesn't deal with OSC blobs properly, which is what the /serial/block message sends.

We'll need to create a way to designate that a certain message should be encoded as a blob, which will probably be something like square brackets [] around a message.

I'm not sure what the strange readback of the baud rate might be off the top of my head, but I'll have a look.

Thanks for the report.

I am having the same issues when setting the baud rate to 4800 it comes back as 4824 and when trying to read from /block I get "Bad Data"  back no mater what.

Has this issue be fixed?

If not when will it be?

I am trying to hook a ttl gps up to the mc.

Any updates on this?

This doesn't sound like an mchelper issue - maybe firmware. Do other baud rates work for you? What about reading a single character at a time?