Mindboards

I know in NQC, you can use the SetSerialComm, SetSerialPasket, SetSerialData, and SendSerial to send user unique serial strings with varying specs, and bytes. How do you receive a string of serial data though? I know you can use the typical Message() to get the last "message" that was sent, but that only grabs one byte (and it takes something like 9 bytes to send). Sure, it works to communicate this way, but I want to do all of it myself. I don't want the FW to need to be confirming that I send (hex numbers) 55 ff 00 f7 08 12 ed 09 f6 just to convey a single byte (in this case 0x12). Not to mention that it's requirements are very specific (and I don't think very standard) (quote from Dave Baum) "2400 baud, NRZ, 1 start, 8 data, odd parity, 1 stop bit". It would be nice to be able to communicate at at least 9600 baud, but especially be able to use the bytes as I choose.

To the best of my knowledge the RCX firmware VM does not give you access to the inbound serial data. That is all handled for you at the firmware level.

John Hansen

A great excuse to write your own, right Matt ? I know that level of programming might be a bit beyond me...

afanofosc wrote:To the best of my knowledge the RCX firmware VM does not give you access to the inbound serial data. That is all handled for you at the firmware level.

John Hansen

Okay. You have done a a huge amount with the FW and such for the NXT, but have you done anything for the RCX, as far as FW? Do you think you could point me in the right direction to try it for myself? Or is it way beyond my abilities? I understand that I would probably be the only one to benefit, as the RCX has all but been put aside by everyone, so don't worry about it too much. I just thought though, that it might be kinda cool to be able to have better networking (addressing, and higher speed) for all my RCX's.

nxtreme wrote:A great excuse to write your own, right Matt ? I know that level of programming might be a bit beyond me...

I would like to at least know what it would take to attempt it.

Another thing that would be AWESOME, is support for I2C (even if it takes a bit of additional hardware).

mattallen37 wrote:I would like to at least know what it would take to attempt it.

Another thing that would be AWESOME, is support for I2C (even if it takes a bit of additional hardware).

And as the RXC is still widely available on eBay and BrickLink, for sometimes less than $30 US, it would be a nice way to expand current collections...

Mindsensors used to make a RCX I2C "converter". They no longer produce it but that might be good; if you ask them nicely, they might give you schematics and PCB files. I could almost reproduce it from the pictures, would just need one of the other side.

nxtreme wrote:And as the RXC is still widely available on eBay and BrickLink, for sometimes less than $30 US, it would be a nice way to expand current collections...

Exactly, they are as cheap as an Arduino. I normally only pay around $25 with shipping.

nxtreme wrote:Mindsensors used to make a RCX I2C "converter". They no longer produce it but that might be good; if you ask them nicely, they might give you schematics and PCB files. I could almost reproduce it from the pictures, would just need one of the other side.

Yea, I had seen that. One big downside to that though, is that it uses the IR port, not allowing any other IR communication. I have contacted mindsensors about the RCX stuff in general, but never got any reply. It seems to be fairly hard to communicate with them.

The RCX firmware source code was never released so it would be very difficult to change the firmware to give a running program access to the incoming serial data, at least not to the best of my knowledge. Philo or others may know better than I do.

John Hansen

mattallen37 wrote:I know in NQC, you can use the SetSerialComm, SetSerialPasket, SetSerialData, and SendSerial to send user unique serial strings with varying specs, and bytes. How do you receive a string of serial data though? I know you can use the typical Message() to get the last "message" that was sent, but that only grabs one byte (and it takes something like 9 bytes to send). Sure, it works to communicate this way, but I want to do all of it myself. I don't want the FW to need to be confirming that I send (hex numbers) 55 ff 00 f7 08 12 ed 09 f6 just to convey a single byte (in this case 0x12). Not to mention that it's requirements are very specific (and I don't think very standard) (quote from Dave Baum) "2400 baud, NRZ, 1 start, 8 data, odd parity, 1 stop bit". It would be nice to be able to communicate at at least 9600 baud, but especially be able to use the bytes as I choose.

Given this depth of interest, it sounds to me like you might be interested in the BrickOS project that is also here on SourceForge. There does seem to be a certain practical limit to IR transmission speed. 4800 baud has been achieved, but speeds above that seem flaky. Still, at that lower level, 0x12 can be communicated in one byte instead of two, so even though you might be running at 4800, your speed is effectively double that compared to the standard Lego RCX IR protocol.

There is a good bit of information on the lugnet newsgroups under lugnet.robotics.rcx.legos. In particular, I would note the following thread that list a number of updates to BrickOS that haven't yet been committed to the source repository:
* http://news.lugnet.com/robotics/rcx/legos/?n=4057

I also have an additional patch in queue that I have not yet had opportunity to post, plus there is a list of other things on my "would like to see done" list.

Excited to find that someone else is interested in the RCX...today is the first I've come across this Mindboards forum.


Thanks,
Matthew

mesheets wrote:Given this depth of interest, it sounds to me like you might be interested in the BrickOS project that is also here on SourceForge. There does seem to be a certain practical limit to IR transmission speed. 4800 baud has been achieved, but speeds above that seem flaky. Still, at that lower level, 0x12 can be communicated in one byte instead of two, so even though you might be running at 4800, your speed is effectively double that compared to the standard Lego RCX IR protocol.

There is a good bit of information on the lugnet newsgroups under lugnet.robotics.rcx.legos. In particular, I would note the following thread that list a number of updates to BrickOS that haven't yet been committed to the source repository:
* http://news.lugnet.com/robotics/rcx/legos/?n=4057

I also have an additional patch in queue that I have not yet had opportunity to post, plus there is a list of other things on my "would like to see done" list.

Excited to find that someone else is interested in the RCX...today is the first I've come across this Mindboards forum.


Thanks,
Matthew

I am quite interested in the BrickOS project, but I have never been quite able to grasp the setup process enough to get it going.

Actually, the default speed for the RCX is 2400 baud. Increasing speed to 4800 would require a different FW (to receive). Increasing to 4800, AND changing the protocol would make for some really impressive speeds.

According to the TSOP datasheet, the max continuous speed is (IIRC) rated either 2400 or 4800 baud. That is likely why it gets not so clear above 4800.

What I want, is a way to access every byte coming in, despite the header and checksum... It would allow me to implement my own protocol for user-bytes.

I really like the RCX. Even though it is very limited when compared to the NXT, it is able to do quite a lot on it's own. In some ways, I like it much more than the NXT. It uses MUCH less power, it is a lot smaller, and it is really cheap.

I'm glad you found us

Yes, the setup for BrickOS is a bit involved. In addition to what was noted in the USB driver thread, another reason for my interest in a Linux distribution was providing a means to greatly reduce the complexity of the setup. Most of BrickOS is written in C, so it is well-suited to the Linux environment.

As to 4800 baud and changing the protocol, BrickOS supports that. Technically (i.e. based on Lego's documentation), the USB Tower supports baud rates even higher than that. Carrier frequency plays a role, too. In their standard configuration, newer RCX units have a carrier frequency double that of the original units. For more details, there is some discussion on lugnet about that. Also, some people have hacked the IR serial communication capabilities to put Bluetooth support on the RCX. The synopsis of what is involved with that mod is incorporating a serial to Bluetooth adapter on the RCX, and then the computer establishes the serial connection via Bluetooth.

For the protocol, there are a couple protocol layers which generally are referred to collectively as LNP. Using one of the LNP layers, you can access data transmissions on a byte-by-byte basis. I would strongly recommend trying to leverage and/or build off the capabilities of LNP rather than attempting to start from scratch. I believe leJOS also incorporated LNP support.

Combine the baud rate and protocol modifications, and you have firmware downloads that occur in ¼ of the time of the standard Lego firmware download. Take either the baud rate modification by itself or the protocol modification by itself, and the transmission speed is still ½ that of what the standard Lego software does.

On of the capabilities I like about the RCX is its ability to generate DCC waveforms, such as are used to control model railroads and accessories. A pbForth and a patched BrickOS both provide these capabilities (leJOS and the standard firmware can't provide the necessary time granularity). As I'm sure you already know (but for the benefit of others), with DCC, you can actually control more than three motors (provided the motor is equipped with a DCC decoder) without resorting to multiplexing (though an additional power source [booster in DCC parlance] would likely be necessary). I see from another post that you are into model railroading, too.

Also, perhaps it's just my perception, but the RCX--possibly because of its novelty--seemed to inspire a broader development community and more diversity in the alternative firmware, languages, and tools that were created, not to mention all the reverse engineering that went into it. One downside to that was sustainability and fragmentation, but I still find all the diversity intriguing. I've found record of at least 17 firmware projects, plus a few firmwares had support for more than one language. Obviously, quite a few alternative programming language implementations were created around Lego's standard firmware, and I've found record of at least 6 different programming languages for BrickOS.