Need Help regarding BlueSmirf and RCB3.
by PaulP
Tue Feb 27, 2007 6:01 pm
O.K.
I managed to get the latency down to 25mS approx and it works, all my commands get sent and acted upon and replies come back. Yippee...
Or maybe NOT....
The problem is, that as of this moment, if you close the comms port after sending Fast Data Mode, it reverts to Normal Data mode so it only works from code I've written.
Closing my code to open H2H resets the smirf and as yet I've not found a way of retaining the setting in the Smirf.
But it proves the concept. The thing works now to iron the bugs...
I managed to get the latency down to 25mS approx and it works, all my commands get sent and acted upon and replies come back. Yippee...
Or maybe NOT....
The problem is, that as of this moment, if you close the comms port after sending Fast Data Mode, it reverts to Normal Data mode so it only works from code I've written.
Closing my code to open H2H resets the smirf and as yet I've not found a way of retaining the setting in the Smirf.
But it proves the concept. The thing works now to iron the bugs...
by shsan
Wed Feb 28, 2007 12:30 am
PaulP,
Thanks a lot for the pdf, I'll try to reproduce that here this weekend.
I still can't believe that I was just a resistor away from the solution...
When you say that you managed to get the latency down to 25ms, did you changed something on the BlueSmirf or is it just the wait that you modified?
I'll modify my RCB3 API to include a direct connection through a BlueSmirf module. I already have the code, I'll just need to add the delay.
Once that's done, I'll also release the code.
Yes it's a pain about the FastMode, I don't see how we can avoid that issue so it's likely that the H2H will never work with the BlueSmirf unless someone writes a virtual COM port doing the right thing (which probably quite some work).
Thanks a lot for the pdf, I'll try to reproduce that here this weekend.
I still can't believe that I was just a resistor away from the solution...
When you say that you managed to get the latency down to 25ms, did you changed something on the BlueSmirf or is it just the wait that you modified?
I'll modify my RCB3 API to include a direct connection through a BlueSmirf module. I already have the code, I'll just need to add the delay.
Once that's done, I'll also release the code.
Yes it's a pain about the FastMode, I don't see how we can avoid that issue so it's likely that the H2H will never work with the BlueSmirf unless someone writes a virtual COM port doing the right thing (which probably quite some work).
by PaulP
Wed Feb 28, 2007 12:57 am
shsan, you may have just nailed the problem..
but first, the problem with the latency goes away when you code yourself.
just send "+++" followed by chr(13) then wait a second, send "ATMF" followed by chr(13) and its there. All my API stuff works with it, I've even managed to get the thing to respond to my XDA.
The problem is that closing the comm port resets the port to normal speed. I have a piece of software that allows you to create Virtual, Back to Back Ports. If I write a piece of code that opens the smirf and sets it up, then just pass thru any data from the virtual port to the real port, then H2H opens a virtual port and never gets to close the real port....
If you follow my meaning.....
Somewhere in my head that makes sense I think
but first, the problem with the latency goes away when you code yourself.
just send "+++" followed by chr(13) then wait a second, send "ATMF" followed by chr(13) and its there. All my API stuff works with it, I've even managed to get the thing to respond to my XDA.
The problem is that closing the comm port resets the port to normal speed. I have a piece of software that allows you to create Virtual, Back to Back Ports. If I write a piece of code that opens the smirf and sets it up, then just pass thru any data from the virtual port to the real port, then H2H opens a virtual port and never gets to close the real port....
If you follow my meaning.....
Somewhere in my head that makes sense I think
by shsan
Wed Feb 28, 2007 1:10 am
Ok perfect, I already had the ATMF in my code, I was not sure that it was enough.
The documentation was specifying that anything above 60Kbps needed it to work properly so I had put that from the start.
I totally follow what you said, I was expecting something similar could be done.
Do you mean you already have that piece of software? If yes, could you tell me what's the name of that software?
It seems to be a handy tool to have around.
Since I am almost sure that it would be a must have for any communication with bluetooth module anyway. Since you need to configure the COM speed on the bluetooth module, you always need to send some commands.
OK it could perhaps be done once and put in eeprom.
The documentation was specifying that anything above 60Kbps needed it to work properly so I had put that from the start.
I totally follow what you said, I was expecting something similar could be done.
Do you mean you already have that piece of software? If yes, could you tell me what's the name of that software?
It seems to be a handy tool to have around.
Since I am almost sure that it would be a must have for any communication with bluetooth module anyway. Since you need to configure the COM speed on the bluetooth module, you always need to send some commands.
OK it could perhaps be done once and put in eeprom.
by PaulP
Wed Feb 28, 2007 1:16 am
Its a cracking company
www.eltima.com
I use their serial port monitor as it can attach to a port that is already open by another application and tell you what is being sent.
There are 2 flavours of virtual ports, one that does all the work for you, the other is as an ActiveX. I'm trying to talk our buying department into purchasing a copy but not got anywhere yet. They keep asking what I want it for.....
I'm still waiting for a response from SparkFun as I'm sure it can be held by the unit itself but I can't work out how?
www.eltima.com
I use their serial port monitor as it can attach to a port that is already open by another application and tell you what is being sent.
There are 2 flavours of virtual ports, one that does all the work for you, the other is as an ActiveX. I'm trying to talk our buying department into purchasing a copy but not got anywhere yet. They keep asking what I want it for.....
I'm still waiting for a response from SparkFun as I'm sure it can be held by the unit itself but I can't work out how?
by shsan
Wed Feb 28, 2007 1:21 am
Yes I just found them via google.
I also found this:
http://www.virtualperipherals.com/Virtu ... iption.asp
It's an SDK which should allow us to do exactly the same thing and perhaps for free.
I have not taken the time to look at the docs yet but it sounds interesting.
I also found this:
http://www.virtualperipherals.com/Virtu ... iption.asp
It's an SDK which should allow us to do exactly the same thing and perhaps for free.
I have not taken the time to look at the docs yet but it sounds interesting.
Bluetooth
by ryann2k1
Wed Feb 28, 2007 4:49 am
Hi PaulP,
Currently, I am using DC supply source from RCB-1 for BlueSMiRF.
In your configuration, do you still connect CTS and RTS (in BlueSMiRF board)? since J1 has already connected,as the manual article showed.
looking forward to your respond
Cheers
ryann2k1
by PaulP
Wed Feb 28, 2007 11:16 am
To test and build I ran originally from a variable power supply, initially at 5V then wound it up to 10.8V to prove the regulator. Now its running off the KHR-1HV internal battery.
The jumper was open circuit on my board when it arrived so I put the Link in. If you are sure its made on your board then the external link isnt necessary..
The jumper was open circuit on my board when it arrived so I put the Link in. If you are sure its made on your board then the external link isnt necessary..
by PaulP
Wed Feb 28, 2007 6:15 pm
Right, well ATSW25 will force the Smirf to retain the Fast setting.
Unfortunately, I now have a Smirf that I'm locked out of. It won't accept +++ anymore and SparkFun seem confused that a Power-Off doesn't clear it..
It makes a slight improvement to H2H but with a little bit more delving I've hit the next issue.
I'm assuming, because the RCB doesn't have a proper UART in it, the data is just clocked in and it gives up once a specific time has passed. The data may actually be arriving but its not in time so it stops.
I tried to read the data back from the RCB into the Data Table and its gets 1 or 2 motion names then times out.
I'm beginning to think that the RCB is gonna kill this project. It's just not flexible enough
Unfortunately, I now have a Smirf that I'm locked out of. It won't accept +++ anymore and SparkFun seem confused that a Power-Off doesn't clear it..
It makes a slight improvement to H2H but with a little bit more delving I've hit the next issue.
I'm assuming, because the RCB doesn't have a proper UART in it, the data is just clocked in and it gives up once a specific time has passed. The data may actually be arriving but its not in time so it stops.
I tried to read the data back from the RCB into the Data Table and its gets 1 or 2 motion names then times out.
I'm beginning to think that the RCB is gonna kill this project. It's just not flexible enough
by shsan
Thu Mar 01, 2007 12:42 am
Ok
So forcing the Fast mode into eeprom is not a good idea
If I remember the docs correctly, I think you can get it back by putting one pin to VCC at the boot. Can't remember which pin.
The problem you are describing are really annoying. And it would kill my project too.
This is why I already started to take a serious look at the Bioloid kit. I think it's the only one for which you can write your own firmware (using an ATMEGA128).
I also want to take a look at the Motion Processor for the KHR2 but so far we don't have any Command Reference for it. But since it has a flashable firmware too, it could be upgraded.
That is if there isn't a new one coming soon or something like that.
Another avenue to explore would be to put a small Atmega linked to the RCB3 and to link the BlueSmirf to the Atmega. A small program to deal with the delays might do the trick. That was my first idea for my project but I messed up my atmega apparently and it's not responding when I am trying to flash it, so I can't really try.
So forcing the Fast mode into eeprom is not a good idea
If I remember the docs correctly, I think you can get it back by putting one pin to VCC at the boot. Can't remember which pin.
The problem you are describing are really annoying. And it would kill my project too.
This is why I already started to take a serious look at the Bioloid kit. I think it's the only one for which you can write your own firmware (using an ATMEGA128).
I also want to take a look at the Motion Processor for the KHR2 but so far we don't have any Command Reference for it. But since it has a flashable firmware too, it could be upgraded.
That is if there isn't a new one coming soon or something like that.
Another avenue to explore would be to put a small Atmega linked to the RCB3 and to link the BlueSmirf to the Atmega. A small program to deal with the delays might do the trick. That was my first idea for my project but I messed up my atmega apparently and it's not responding when I am trying to flash it, so I can't really try.
by PaulP
Thu Mar 01, 2007 1:36 am
The pin you are describing is PIO4 but.... On this variation the spin is strapped to Ground without a resistor so it can't be strobed. Thats what SparkFun are looking at...
Your other comment follows what I've been thinking more and more..
I've been following some dialogs about the LynxMotion SSC-32 Servo Controller. As a servo controller it is a lot more capable than the RCB.
It can run at 10.8V so the servos aren't a problem.
It can read back servo position. Not directly from the Servo itself but from the Controller. Movement is handled differently and the Controller always knows where each servo is.
It has genuine RS232 but also has links you can remove to allow TTL to be connected so Smirf will work.
It seems a lot of thought has gone into the board and it shouldnt be too much problem to re-create the required functions.
At first glance, it may even be possible to map or translate RCB motions already created to the unit.
The RCB does have brains on it so it can remember motions etc but as we have found, they aren't that good.
Initially, the brains could be located on the P.C. allowing development in whatever favourite language you have. Later the brains can be transferred to an Atmel or similar (which the board has links already fitted for).
Also the firmware is open source and upgradeable....
One other thing I did think about was that 3 or more robots now use the RCB3 or a variation. It may be a viable alternative for others to use as well.
I've seen comments about the similarities and differences with Manoi.
It uses the same board therefore its motion files are the same, the only difference will be the vlaues stored for the motions, not the formats of the files. The trims for the home position are the same as well.
A translator for 1HV would also work for Manoi.
Your other comment follows what I've been thinking more and more..
I've been following some dialogs about the LynxMotion SSC-32 Servo Controller. As a servo controller it is a lot more capable than the RCB.
It can run at 10.8V so the servos aren't a problem.
It can read back servo position. Not directly from the Servo itself but from the Controller. Movement is handled differently and the Controller always knows where each servo is.
It has genuine RS232 but also has links you can remove to allow TTL to be connected so Smirf will work.
It seems a lot of thought has gone into the board and it shouldnt be too much problem to re-create the required functions.
At first glance, it may even be possible to map or translate RCB motions already created to the unit.
The RCB does have brains on it so it can remember motions etc but as we have found, they aren't that good.
Initially, the brains could be located on the P.C. allowing development in whatever favourite language you have. Later the brains can be transferred to an Atmel or similar (which the board has links already fitted for).
Also the firmware is open source and upgradeable....
One other thing I did think about was that 3 or more robots now use the RCB3 or a variation. It may be a viable alternative for others to use as well.
I've seen comments about the similarities and differences with Manoi.
It uses the same board therefore its motion files are the same, the only difference will be the vlaues stored for the motions, not the formats of the files. The trims for the home position are the same as well.
A translator for 1HV would also work for Manoi.