Baud rates for the AVRcam

[Guest]

So, I've been adding support for multiple baud rates (115.2, 57.6, 38.4, 19.2, and 9.6 Kbps) to the AVRcam recently. I have also added an auto-baud feature so that setting the baud rate doesn't require any jumper settings...just ping the system (by sending the "PG" command), and the baud rate gets set.

I was wondering if baud rates lower than 9.6 Kbps would be useful for developers? I don't have much experience with the BASIC Stamps, but I understand that those folks seem to really like 9.6 Kbps serial (don't know if its a hardware limitation or not). At 9.6 Kbps, two objects can be tracked simultaneously at 30 frames/second. at 19.2 Kbps, 5 objects can be tracked at 30 frames/sec. 38.4 and above allow for the full 8 objects to be tracked simultaneously.

What do you think? Would other baud rates be useful? Anyone really need 300 baud serial?

[matrixrunner]

The common Basic Stamp 2 does not have a UART. So the operating software needs to poll the pins to receive serial input. 9600 is about as fast as you can do that. This is a limitation of the PIC processor they chose when the BS2 was new, now some newer BS version ones may go faster but the BS2 is the really common one.

If you supported anything less than that, something less than 4800 seems about as slow as you would want to go. It would also be helpful if instead of tracking less colors that you track not as fast. So you could get 15 frames per second, at a slower baud rate.

[Guest]

So the operating software needs to poll the pins to receive serial input. 9600 is about as fast as you can do that.

Ok...I figured it was something like this

It would also be helpful if instead of tracking less colors that you track not as fast. So you could get 15 frames per second, at a slower baud rate.

I have thought about reducing the framerate to support more objects at the lower baud rates. There is a way to do it, but it requires a second version of the core pixel-capture routine that would be tailored to the slower frame rate (i.e., 15 frames/sec). This wouldn't be that bad to implement, and may be added (or, it sounds like a great starter project for someone to try with the system...remember: its open-source Post a reply if interested, and we can chat about how this would be done).

[Guest]

John,

Looks like a nice unit. I'm a CMUcam user now, but it looks like you are on the x-mass list!

If you went to 4800 baud, it opens the unit up for use by the BS1 and the picaxe microcontroller series. sometimes you don't want to use more.

Larry

[Guest]

If you went to 4800 baud, it opens the unit up for use by the BS1 and the picaxe microcontroller series. sometimes you don't want to use more.

Good to know...I'll just go ahead and add in support for 4800 baud if it has even the potential for being useful.

Also, I mentioned earlier that a re-write of the low level pixel acquisition routine would be needed to support more objects at lower frame rates. Not so. I was thinking about it more on my drive home from work today, and it can be done without doing this. I'm thinking about adding a command that would allow the user to switch between favoring frame rate with reduced object tracking, or favor object tracking with reduced frame rate. Again, this only matters if you are running at the lower baud rates.

I'll add this in in the near future.

[Larry]

John,

Is variable Baud rate still on your radar, or have you shelved it for the immediate future? I'm working with a coupe of slow processors and need a camera for my next robot.

-Larry

[Guest]

Hello,
Its still on my radar. I just have a ton of other stuff going on right now which doesn't allow me to spend as much time as I'd like playing with/enhancing the system. Now that a number of the issues with v 1.2 are worked out (and v 1.4 is released), I'll be trying to get back to add the baud rates in. I have a feeling a few of the bug fixes in v 1.4 are going to alleviate a few of the oddities I saw when I first started adding additional baud rate support (I actually had a version that supported multiple baud rates, but some weird things were happening at a few of the baud rates that I couldn't explain, so I shelved it...I now think these were related to a few bugs that were fixed in v 1.4).

Stay tuned...I'll post when I get the time to work on it...

[Larry]

I don't know if it helps with your code issues, but a different build that just supported, say, 9600BAUD would work for me.

-Larry