Need Help regarding BlueSmirf and RCB3.
by heke
Fri Feb 23, 2007 2:20 pm
shsan wrote:It is an interesting route indeed.
If i had a RS232 cables and not the USB one. I don't remember seeing the KHR2 with an RS232 cable.
But what is the difference between KHR-1 and KHR-2 ? KHR-2 has an USB <-> rs-232 -converter which plugs in to the PC. The white/red/black cable is a rs-232 -cable. Now between the USB and rs-232 we are planning to put bluetooth. Meltdown has succeded in it by using a ready-made bluetooth<->rs-232 -converter. And isn't bluesmirf practically a similar device ?
by shsan
Fri Feb 23, 2007 2:32 pm
As far as I am aware the White,Red,Black is not an RS232 cable.
The RS232 specifies Negative value for 0 (below -3) and Positive (above 3) for 1.
The RCB3 is outputting 5V for 1 and 0V for 0. And receiving 3.3V for 1 and 0 for 0V so nothing to do with RS232 Level.
It's all TTL level here.
The BlueSmirf is Inverted TTL.
The RS232 specifies Negative value for 0 (below -3) and Positive (above 3) for 1.
The RCB3 is outputting 5V for 1 and 0V for 0. And receiving 3.3V for 1 and 0 for 0V so nothing to do with RS232 Level.
It's all TTL level here.
The BlueSmirf is Inverted TTL.
by heke
Fri Feb 23, 2007 2:41 pm
shsan wrote:As far as I am aware the White,Red,Black is not an RS232 cable.
The RS232 specifies Negative value for 0 (below -3) and Positive (above 3) for 1.
The RCB3 is outputting 5V for 1 and 0V for 0. And receiving 3.3V for 1 and 0 for 0V so nothing to do with RS232 Level.
It's all TTL level here.
The BlueSmirf is Inverted TTL.
Ok, good to know. Then those ready-made modules won't work either.
How about that "low speed serial connector" on RCB-3J which can be connected to KRR-1, KRR-2 etc. What are the levels in the connector ?
by heke
Fri Feb 23, 2007 2:56 pm
shsan wrote:I don't know about the low speed one.
But since there is an existing Wireless connection for it from Kondo, there is no real need to do anything special.
Well I won't look into it
I checked the Kondo web shop, and there are several wireless products for KHR's. But I quess most of them are one way only, I mean that commands can be only sent to robot, nothing can be received from the robot. So wireless teaching is not possible. But bluetooth would solve that problem.
Except item code 01105. What is it ? Looks like wireless on USB. Or what is it ?
by shsan
Fri Feb 23, 2007 3:03 pm
This is the kit for the Low Speed I was talking about, it's replacing the remote control.
I think you can send data to that link from the RCB3 but it's very limited (and 2400Bps only).
In fact, the RCB recognizes only 1 packet format from the Remote control.
But there are still unclear things about that packet since there is a field command in it but no description for it.
I think you can send data to that link from the RCB3 but it's very limited (and 2400Bps only).
In fact, the RCB recognizes only 1 packet format from the Remote control.
But there are still unclear things about that packet since there is a field command in it but no description for it.
by PaulP
Mon Feb 26, 2007 4:53 pm
shsan or whoever is watching this thread...
I have received my bluesmirf and like shsan, gone thru the moves, data looked inverted so passed thru an inverter both ways. Data looks clean but does nothing for robot...
So i pulled apart the usb dongle that comes with the KHR....
It contains an FTDI FT232BL chip....
Info is here
http://www.alphamicro.net/components/pr ... id~474.asp
Datasheet is here
http://www.ftdichip.com/Documents/DataS ... 232b18.pdf
Indeed it is a USB RS232 Uart but its typical configuration is for RS485 line driving...
The RCB Manual does not label the pins as TX and RX, it labels them as GND and Signal lines. This is typical of RS485...
Unfortunately the voltages are not. Usually on RS485 (if i remember right) one is usually high and the other low and they switch over as bits are sent.
One other possibility is that the RCB3 may not have a UART, in which case it is common to have a data line and an enable line.
When the enable is in one state it will transmit from the PC to the RCB, in the other state from the RCB to the PC.
This would explain what you were seeing shsan when you said it appeared to be sending and receiving at the same time. Its not actually its just using the same line to send but the PC UART isnt clever enough to know so it thinks its rxing. Most applications that use RS485 line drivers know to ignore the RX when you are TXing..
The components around the 3 pins output in the dongle are too small for me to identify though the labels indicate a couple of 'R' components which is usually resistors and a 'Q' component. Arent they usually Transistors?
Has the KHR-1HV or the KHR-2HV ever been supplied with a 9 pin serial lead rather than the USB one because if anyone has one, it could contain the clues we need.
For the moment I am stumped. I have proven the BlueSmirf right thru to a 9 pin input back to my PC so I am confident that works. I even double inverted the data to prove the inverters were'nt causing any lag.. Its not the Smirf its the RCB i'm fairly sure...
If someone can help it would be awesome...
I have received my bluesmirf and like shsan, gone thru the moves, data looked inverted so passed thru an inverter both ways. Data looks clean but does nothing for robot...
So i pulled apart the usb dongle that comes with the KHR....
It contains an FTDI FT232BL chip....
Info is here
http://www.alphamicro.net/components/pr ... id~474.asp
Datasheet is here
http://www.ftdichip.com/Documents/DataS ... 232b18.pdf
Indeed it is a USB RS232 Uart but its typical configuration is for RS485 line driving...
The RCB Manual does not label the pins as TX and RX, it labels them as GND and Signal lines. This is typical of RS485...
Unfortunately the voltages are not. Usually on RS485 (if i remember right) one is usually high and the other low and they switch over as bits are sent.
One other possibility is that the RCB3 may not have a UART, in which case it is common to have a data line and an enable line.
When the enable is in one state it will transmit from the PC to the RCB, in the other state from the RCB to the PC.
This would explain what you were seeing shsan when you said it appeared to be sending and receiving at the same time. Its not actually its just using the same line to send but the PC UART isnt clever enough to know so it thinks its rxing. Most applications that use RS485 line drivers know to ignore the RX when you are TXing..
The components around the 3 pins output in the dongle are too small for me to identify though the labels indicate a couple of 'R' components which is usually resistors and a 'Q' component. Arent they usually Transistors?
Has the KHR-1HV or the KHR-2HV ever been supplied with a 9 pin serial lead rather than the USB one because if anyone has one, it could contain the clues we need.
For the moment I am stumped. I have proven the BlueSmirf right thru to a 9 pin input back to my PC so I am confident that works. I even double inverted the data to prove the inverters were'nt causing any lag.. Its not the Smirf its the RCB i'm fairly sure...
If someone can help it would be awesome...
by Robo1
Mon Feb 26, 2007 5:43 pm
Hello all
PaulP to my knowledge the RCB has only ever been available in USB format. I tried my self to intergrate a wifi module to the RCB. I got the module working fine but couldn't get it communicating with the bot so it's been sat on the bench.
Hope some one solves this.
bren
PaulP to my knowledge the RCB has only ever been available in USB format. I tried my self to intergrate a wifi module to the RCB. I got the module working fine but couldn't get it communicating with the bot so it's been sat on the bench.
Hope some one solves this.
bren
by PaulP
Tue Feb 27, 2007 12:18 am
I think I may be on to something but I need a confirmation off someone who knows a bit about electronics...
I've confirmed the Red wire is Tx from PC to RCB. Its TTL Inverted and I can make the robot respond. The Led on the PCB flickers and a character is sent back to $0D.
The reply character is deformed, its there, it goes from 0V to 5V at the beginning of the start bit but the following bits dont come down far enough.
The data is definitely there though. Also pressing the start button usually causes an $FF to be sent and I can see that as well but still too high voltage.
I compared this to the USB module. I disconnected the WHite from the module side and I get exactly the same signal, a poor, offset high signal. When I reconnect the white wire to the USB module end, the signal is back all nice and square wavy....
I measured the resistance between the white wire and 0V at the USB module and it reads 1.9Kohms. Would I be right in thinking it needs a pull-down resistor? If so what value?
I've confirmed the Red wire is Tx from PC to RCB. Its TTL Inverted and I can make the robot respond. The Led on the PCB flickers and a character is sent back to $0D.
The reply character is deformed, its there, it goes from 0V to 5V at the beginning of the start bit but the following bits dont come down far enough.
The data is definitely there though. Also pressing the start button usually causes an $FF to be sent and I can see that as well but still too high voltage.
I compared this to the USB module. I disconnected the WHite from the module side and I get exactly the same signal, a poor, offset high signal. When I reconnect the white wire to the USB module end, the signal is back all nice and square wavy....
I measured the resistance between the white wire and 0V at the USB module and it reads 1.9Kohms. Would I be right in thinking it needs a pull-down resistor? If so what value?
by PaulP
Tue Feb 27, 2007 2:30 am
O.K.
I put a 1K2 resistor between the white wire and ground and I now have a good signal.
I have a serial port monitor running on the port and the data is good. When I switch on, I get $FF and a 30 byte stream to indicate the current position. STUNNING.
BUT.....
The delay between $0D and the reply from the RCB is too much. H2H doesn't like it
I have put the Smirf into FastMode and it still isn't quick enough.
I put a 1K2 resistor between the white wire and ground and I now have a good signal.
I have a serial port monitor running on the port and the data is good. When I switch on, I get $FF and a 30 byte stream to indicate the current position. STUNNING.
BUT.....
The delay between $0D and the reply from the RCB is too much. H2H doesn't like it
I have put the Smirf into FastMode and it still isn't quick enough.
by shsan
Tue Feb 27, 2007 11:40 am
Hi PaulP,
Interesting thing. Could you give more details about your final setup then ?
What's your current thought? RS485 or not ? I would think not but since I have not been able to have it working and you do, you might be right.
Just to be sure, you also changed the BlueSmirf to 115200?
Don't think it would work without but you never know.
I'll probably try that again as soon as I have the pieces to replicate your configuration.
I was a bit worry too about the latency but I am surprised that it's causing problem here.
shsan.
Interesting thing. Could you give more details about your final setup then ?
What's your current thought? RS485 or not ? I would think not but since I have not been able to have it working and you do, you might be right.
Just to be sure, you also changed the BlueSmirf to 115200?
Don't think it would work without but you never know.
I'll probably try that again as soon as I have the pieces to replicate your configuration.
I was a bit worry too about the latency but I am surprised that it's causing problem here.
shsan.
by PaulP
Tue Feb 27, 2007 1:08 pm
Essentially its finished and it works. Its not useable because of the protocol and the latency.
The data is readable by the PC quite happily.
The protocol seems to be on a very strict timebase.
The P.C. sends $0D to the RCB...
The RCB responds with $0D and goes into a vary short wait window...
The P.C. must initiate the next command within this window or the RCB goes back to waiting for $0D.
I ran some quick tests last night...
On the USB link the P.C. starts sending within about 35ms.
On the Smirf it takes about 75ms. This is too long.
I'm going to talk to SparkFun about the settings to get the shortest latency possible, hopefully by disabling unecessary stuff and also run some delay tests to see if I can walk out the window width. I'm guessing at about 50ms at the moment...
I will put together a schematic of what I've built though from what you've said, I've essentially got a copy of what you built but with an extra resistor to pull down the replies.
The data is readable by the PC quite happily.
The protocol seems to be on a very strict timebase.
The P.C. sends $0D to the RCB...
The RCB responds with $0D and goes into a vary short wait window...
The P.C. must initiate the next command within this window or the RCB goes back to waiting for $0D.
I ran some quick tests last night...
On the USB link the P.C. starts sending within about 35ms.
On the Smirf it takes about 75ms. This is too long.
I'm going to talk to SparkFun about the settings to get the shortest latency possible, hopefully by disabling unecessary stuff and also run some delay tests to see if I can walk out the window width. I'm guessing at about 50ms at the moment...
I will put together a schematic of what I've built though from what you've said, I've essentially got a copy of what you built but with an extra resistor to pull down the replies.
by shsan
Tue Feb 27, 2007 1:31 pm
Damn, I was so close.
I had tried things like that but probably not the right one.
I almost lost hope
Have you tried just skipping the wait (I know it's ugly), adding a small delay and sending the packet even before receiving the answer might work.
I might be able to meet someone here in Japan who has succesfully done it (linking a bluetooth module with the RCB3), It's probably not the BlueSmirf but I'll post any information that I can get too.
It won't be this week but I'll keep you informed too.
It might work with faster BlueTooth module, some are supposed to go well above 115200 so the latency might be lower on those modules.
I had tried things like that but probably not the right one.
I almost lost hope
Have you tried just skipping the wait (I know it's ugly), adding a small delay and sending the packet even before receiving the answer might work.
I might be able to meet someone here in Japan who has succesfully done it (linking a bluetooth module with the RCB3), It's probably not the BlueSmirf but I'll post any information that I can get too.
It won't be this week but I'll keep you informed too.
It might work with faster BlueTooth module, some are supposed to go well above 115200 so the latency might be lower on those modules.
by PaulP
Tue Feb 27, 2007 4:23 pm
I have done exactly what you said, Waited 30mS and sent it, thats how I confirmed the Tx was working. Jumped to pose like a good little robot..
I have emailed SparkFun just now, they are about 8 hrs behind so should get a response this evening sometime.
Having said all this, what with the other protocol anomalies we've run into, the fact that Kondo are changing the board anyway so ours will be obsolete,(seems strange that actually, release a new controller so soon after releasing a new robot, maybe something fishy there) I might bite the bullet and go ahead with a board change.
Depends on cost but might be worth it
I have emailed SparkFun just now, they are about 8 hrs behind so should get a response this evening sometime.
Having said all this, what with the other protocol anomalies we've run into, the fact that Kondo are changing the board anyway so ours will be obsolete,(seems strange that actually, release a new controller so soon after releasing a new robot, maybe something fishy there) I might bite the bullet and go ahead with a board change.
Depends on cost but might be worth it