I hope you're having fun. To me this is really fun stuff.
I am! I really do get a boost when I'm able to get a problem, even a small one, worked out. And a down-right thrill if I'm able to fix if from something I discovered myself.
I have to give a huge THANK YOU to you and Rforbes for all of your help. Gradually more and more of this is starting to make sense. Having the ability to ask very specific questions and have them answered is what I need to understand this. I've went back and re-read parts of the PE Kit, after working out a problem with your help, and only then did the PE Kit explanation make sense. I guess we all comprehend information differently and just need a little bit different perspective to make it understandable.
I have a long way to go on this project so I'll probably have many more questions. I appreciate you hanging in there for as long as you can stand it.
I'll have to take a break sometime soon to set-up a small router for making PC boards and get that working, but I will see this project through.
I've just discovered the jm_joystick_servo_demo.spin code from the OBEX that uses the MCP3204. That really works nice with the autocal Method. I'm planning to switch my code over to use that instead of the ADC0838 if I can get it to read 8 channels of the MCP3208. I tried to convert the code and I didn't quite get something right. I get the list of channels and 128 and 1502 for each channel, but they do not update. Any idea what needs to be corrected to get this to work? I some other Objects to read the MCP3208 but this one is really stable (at least with the MCP3204.)
Also, what is the etiquette for renaming an Object when you change it as I have with the Jonny Mac code? I want to give full credit to the originator and make it clear that it is not the fruits of my labor.
It's probably because the MCP3208 is a 12 bit ADC and the ADC0838 is an 8 bit. I don't think it's able to read your converter properly.
I might not have explained that as well as I should.
My current TX code uses the ADC0838. It works but after about 15 minutes it looses it's "sync" and no longer displays correct on the PST from the RX.
I discovered the MCP3204 Object that jm had written. I mocked that up and it was really stable. The attached files were my attempt to modify the jm MCP3204 code to access the 8 channels of the MCP3208. I need to get that working first, then I will try to incorporate that code into my TX project to replace the ADC0838.
I've discovered that the "newDataFlag" function was causing the "sync" problems I was having between the TX and RX. I really do want to include that function in the future to avoid having the XBee transmit unless there is new data to be sent, but for now it is commented out. The Switch data is staying sync'ed now so I am continuing. I will revisit in the near future.
I am using a 74HC595 on the RX to drive a Sainsmart 8-channel relay board. I've used Jonny Mac's jm_595_ez_demo code with the '595 and the relay board on a breadboard and it works great. I may have to use the ULN2808 Darlington Array if the load is too great. For now it works. jm_595_ez.spin jm_595_ez_demo.spin
The demo code uses the following to illuminate 8 LEDs. It defines "Pattern" in binary terms.
pub main | pattern
leds.init(6, 5, 7) ' initialize 595 driver
pattern := %0000_0001 ' initialize LED pattern
repeat ' old-school Cylon eyes
repeat
leds.out1(pattern) ' output to one 74x595
waitcnt((MS_001 * 75) + cnt)
pattern <<= 1
until pattern == %1000_0000
repeat
leds.out1(pattern)
waitcnt((MS_001 * 75) + cnt)
pattern >>= 1
until pattern == %0000_0001
That demo code calls the Out1 Method from the following Object, which then calls the Out Method.
pub out(bits, dolatch)
'' Output byte to 74x595
'' -- optionally latch outputs
bits <<= (32 - 8) ' prep for msb output
' output bits, MSBFIRST
repeat 8
outa[dout] := (bits <-= 1) & 1 ' output a bit
outa[clk] := 1 ' clock the bit
waitcnt(US_005 + cnt)
outa[clk] := 0
waitcnt(US_005 + cnt)
if dolatch
outa[latch] := 1 ' latch the outputs
waitcnt(US_005 + cnt)
outa[latch] := 0
pub out1(dev1)
'' Output to one 74x595
out(dev1, true)
I send the TX Switch data with the following
XB.dec(Switches)
XB.tx(CR)
In my RX code I receive the switch data from the TX via an XBee with the following code.
DataIn := XB.rxDec 'receive data
SR595.out1(DataIn)
outa[16..23] := DataIn
The data displays on the 16..23 LEDs correctly so I know the received data is good and the SR595 call is not holding up the code. I call the jm_595_ez.spin with "SR595.out1(DataIn)" but I get no output from the '595. The jm_595_ez_demo runs fine with no wiring changes so I know that code is good and the hardware is good.
The difference I see is that the demo code defines "Pattern" in binary terms, while I am not. I've tried several different ways to call the '595 Object but nothing had worked.
Questions:
Should I transmit that data in a different format?
Do I need to convert the data on the RX end to a binary format before calling the '595 Object to use it? I don't see why I would have to.
I've discovered that the "newDataFlag" function was causing the "sync" problems I was having between the TX and RX. I really do want to include that function in the future to avoid having the XBee transmit unless there is new data to be sent, but for now it is commented out. The Switch data is staying sync'ed now so I am continuing. I will revisit in the near future.
This is something you should be concerned about. It means something isn't doing what you want it to do (it's probably doing what you're telling it to do (don't you hate that?)).
Did you call the "init" method for the '595 object?
The binary, decimal and hex formats are conviences for human readers. All data is stored in binary so it doesn't matter what from you input it as.
If you attach both your TX and RX code as attachements, I'll take a look at them.
I do call the '595 init. I can't see a reason that I can't get the LEDs to light.
I really do want to get that function working. I'll power the TX with a LIPO battery but I'm using the 100 mW XBees and it will draw 250 mA when transmitting so I need to minimize the transmit time as much as possible.
Do you think I should move this thread to the Projects forum, or start an new thread in a particular forum since I'll be developing this for a while and it will not necessarily stay within the XBee Tutorial subject?
You're still making the same mistakes in your RX code that I showed you in post #30.
As I've also mentioned several times, you should call "Start" or "Init" methods from within the cog you plan to used the objects. I think these two problems are making the '595 object not work as expected.
Here's the fixed start method.
(This seems familiar.)
Pub Start
PC.start(PC_Rx, PC_Tx, 0, PC_Baud) ' Initialize comms for PC
XB.start(XB_Rx, XB_Tx, 0, XB_Baud) ' Initialize comms for XBee
SR595.init(dpin, cpin, lpin)
SR595.cleanup
'cognew(SERVOControl,@stack2) ' Start cog for Servo positioning
'SERVO.Start
SERVOControl
I commented out the call to "SERVO.Start" since you make the same call in the "SERVOControl" method.
You're still making the same mistakes in your RX code that I showed you in post #30.
As I've also mentioned several times, you should call "Start" or "Init" methods from within the cog you plan to used the objects. I think these two problems are making the '595 object not work as expected.
Here's the fixed start method.
(This seems familiar.)
Pub Start
PC.start(PC_Rx, PC_Tx, 0, PC_Baud) ' Initialize comms for PC
XB.start(XB_Rx, XB_Tx, 0, XB_Baud) ' Initialize comms for XBee
SR595.init(dpin, cpin, lpin)
SR595.cleanup
'cognew(SERVOControl,@stack2) ' Start cog for Servo positioning
'SERVO.Start
SERVOControl
I commented out the call to "SERVO.Start" since you make the same call in the "SERVOControl" method.
So, with the cognew(SERVOControl,@stack2) commented out, I'm only using cog(0). Isn't that correct?
I made those changes but I didn't get the '595 to function correctly until I commented out that SR595.cleanup Method call. I assumed it would have improved the functionality...but I was wrong.
Did you see any changes that would help the newDataFlag function in the TX?
I appreciate your continued assistance. I would have been completely disillusioned without it.
Did you see any changes that would help the newDataFlag function in the TX?
I'm guessing the rxflush in the RX code may be dumping the data before it has a chance to be read.
I'd suggest getting rid of "rxflush" calls unless they are really needed for some reason.
It's been too long since I've used "AT" commands with XBees (I use Nordic nRF24L01+ modules most of the time). I don't know what you're trying to do with the AT_Config call. I would suggest to go back to working code and only changing one thing at a time to make sure a change doesn't causes a problem.
I removed all of the config commands except the XB.AT_Config(string("ATDB")) in the RX code which polls the TX for the RSSI (signal strength) which I want to monitor. I agree...no use having anything else in there that isn't absolutely necessary.
It's good to get that '595 working. I'll now go back and re-enable that newDataFlag commands and work on that.
Before I tackle that newDataFlag function, I want to verify that I can control that Sabertooth 2x25 with the RX.
I haven't had a servo connected to the RX while I got that '595 working. Now with a servo connected to Servo Channel 3, the servo movement is really jerky.
I then discovered that the servo movement is nice and smooth if I comment out the entire block of code that polls the TX for the RSSI and displays it. I can leave that commented out but I'd like to get smooth servo movement with that function active.
From my very limited experience, it looks to me like only two cogs are being used: cog(0) is by default the first launched (in PUB Start) and, without a cognew anywhere, PUB ServoControl is also run in cog(0). And cog(1) is called by FullDuplexSerial which is called by the XBee_Object's XB.start Method. Is that correct?
I think running the servos from their own cog would allow smoother movement. How would I start a cog just to control the servos?
The servos are stable when the joysticks are un-touched. Even when the joysticks are held at their travel limit, the servos catch up and are then stable. The actual servo movement is only jerky while it is "catching up" to the joystick position. If I slam the joystick to it's end point, the servo makes 3 or 4 big movements to reach the end of it's travel, then stays there calmly until the joystick is moved again.
I added the rxflush after seeing it in the XBee tutorial code and Rforbes included in his examle from post # 15. I'll comment it out and see if it makes a difference. I'll leave it in there so I can check the difference with and without it as the code is developed further.
The rxflushes are dumping the data you're receiving that's way the servos take so long to catch up because the Prop dumps the received messages so frequently without looking at them. Get rid of all but one rxdump! The one rxdump should not be part of your main loop; it should be called once at the beginning of your program(if you want it, but you don't need it). Your program is fighting itself.
I commented out all of the rxflush statements in the main loop but the servo is still jerky. Just to check, I commented out the last rxflush (outside the main loop) and no change. Still jerky.
The servo movement smoothed only when the block of code that polls the TX for the RSSI and displays it is commented out. That continued transmission to the TX to check the RSSI seems to be causing the entire loop to lag.
How would I start a separate cog for the Servo Object? I think I'll have spare cogs. Or, perhaps the XBee and all of its RX and TX activity should be on a cog separate from the rest of the code. I plan to have data flowing both ways (telemetry from the bot) so the traffic will be heavier as this code develops.
Comments
I am! I really do get a boost when I'm able to get a problem, even a small one, worked out. And a down-right thrill if I'm able to fix if from something I discovered myself.
I have to give a huge THANK YOU to you and Rforbes for all of your help. Gradually more and more of this is starting to make sense. Having the ability to ask very specific questions and have them answered is what I need to understand this. I've went back and re-read parts of the PE Kit, after working out a problem with your help, and only then did the PE Kit explanation make sense. I guess we all comprehend information differently and just need a little bit different perspective to make it understandable.
I have a long way to go on this project so I'll probably have many more questions. I appreciate you hanging in there for as long as you can stand it.
I'll have to take a break sometime soon to set-up a small router for making PC boards and get that working, but I will see this project through.
Thanks,
falcon
Also, what is the etiquette for renaming an Object when you change it as I have with the Jonny Mac code? I want to give full credit to the originator and make it clear that it is not the fruits of my labor.
jm_joystick_servo_demo (MCP3208).spin
jm_mcp3208_ez.spin
Thanks,
falcon
I might not have explained that as well as I should.
My current TX code uses the ADC0838. It works but after about 15 minutes it looses it's "sync" and no longer displays correct on the PST from the RX.
I discovered the MCP3204 Object that jm had written. I mocked that up and it was really stable. The attached files were my attempt to modify the jm MCP3204 code to access the 8 channels of the MCP3208. I need to get that working first, then I will try to incorporate that code into my TX project to replace the ADC0838.
Thanks for the reply,
falcon
I am using a 74HC595 on the RX to drive a Sainsmart 8-channel relay board. I've used Jonny Mac's jm_595_ez_demo code with the '595 and the relay board on a breadboard and it works great. I may have to use the ULN2808 Darlington Array if the load is too great. For now it works.
jm_595_ez.spin
jm_595_ez_demo.spin
The demo code uses the following to illuminate 8 LEDs. It defines "Pattern" in binary terms.
pub main | pattern leds.init(6, 5, 7) ' initialize 595 driver pattern := %0000_0001 ' initialize LED pattern repeat ' old-school Cylon eyes repeat leds.out1(pattern) ' output to one 74x595 waitcnt((MS_001 * 75) + cnt) pattern <<= 1 until pattern == %1000_0000 repeat leds.out1(pattern) waitcnt((MS_001 * 75) + cnt) pattern >>= 1 until pattern == %0000_0001That demo code calls the Out1 Method from the following Object, which then calls the Out Method.
pub out(bits, dolatch) '' Output byte to 74x595 '' -- optionally latch outputs bits <<= (32 - 8) ' prep for msb output ' output bits, MSBFIRST repeat 8 outa[dout] := (bits <-= 1) & 1 ' output a bit outa[clk] := 1 ' clock the bit waitcnt(US_005 + cnt) outa[clk] := 0 waitcnt(US_005 + cnt) if dolatch outa[latch] := 1 ' latch the outputs waitcnt(US_005 + cnt) outa[latch] := 0 pub out1(dev1) '' Output to one 74x595 out(dev1, true)I send the TX Switch data with the following
XB.dec(Switches) XB.tx(CR)In my RX code I receive the switch data from the TX via an XBee with the following code.
DataIn := XB.rxDec 'receive data SR595.out1(DataIn) outa[16..23] := DataInThe data displays on the 16..23 LEDs correctly so I know the received data is good and the SR595 call is not holding up the code. I call the jm_595_ez.spin with "SR595.out1(DataIn)" but I get no output from the '595. The jm_595_ez_demo runs fine with no wiring changes so I know that code is good and the hardware is good.
The difference I see is that the demo code defines "Pattern" in binary terms, while I am not. I've tried several different ways to call the '595 Object but nothing had worked.
Questions:
Should I transmit that data in a different format?
Do I need to convert the data on the RX end to a binary format before calling the '595 Object to use it? I don't see why I would have to.
Any and all responses are appreciated.
falcon
This is something you should be concerned about. It means something isn't doing what you want it to do (it's probably doing what you're telling it to do (don't you hate that?)).
Did you call the "init" method for the '595 object?
The binary, decimal and hex formats are conviences for human readers. All data is stored in binary so it doesn't matter what from you input it as.
If you attach both your TX and RX code as attachements, I'll take a look at them.
I do call the '595 init. I can't see a reason that I can't get the LEDs to light.
I really do want to get that function working. I'll power the TX with a LIPO battery but I'm using the 100 mW XBees and it will draw 250 mA when transmitting so I need to minimize the transmit time as much as possible.
Remote RX_12_02_2012.spin
Remote TX_12_02_2012.spin
Do you think I should move this thread to the Projects forum, or start an new thread in a particular forum since I'll be developing this for a while and it will not necessarily stay within the XBee Tutorial subject?
falcon
As I've also mentioned several times, you should call "Start" or "Init" methods from within the cog you plan to used the objects. I think these two problems are making the '595 object not work as expected.
Here's the fixed start method.
(This seems familiar.)
I commented out the call to "SERVO.Start" since you make the same call in the "SERVOControl" method.
So, with the cognew(SERVOControl,@stack2) commented out, I'm only using cog(0). Isn't that correct?
I made those changes but I didn't get the '595 to function correctly until I commented out that SR595.cleanup Method call. I assumed it would have improved the functionality...but I was wrong.
Did you see any changes that would help the newDataFlag function in the TX?
I appreciate your continued assistance. I would have been completely disillusioned without it.
falcon
I'm guessing the rxflush in the RX code may be dumping the data before it has a chance to be read.
I'd suggest getting rid of "rxflush" calls unless they are really needed for some reason.
It's been too long since I've used "AT" commands with XBees (I use Nordic nRF24L01+ modules most of the time). I don't know what you're trying to do with the AT_Config call. I would suggest to go back to working code and only changing one thing at a time to make sure a change doesn't causes a problem.
It's good to get that '595 working. I'll now go back and re-enable that newDataFlag commands and work on that.
Thanks,
falcon
I haven't had a servo connected to the RX while I got that '595 working. Now with a servo connected to Servo Channel 3, the servo movement is really jerky.
I then discovered that the servo movement is nice and smooth if I comment out the entire block of code that polls the TX for the RSSI and displays it. I can leave that commented out but I'd like to get smooth servo movement with that function active.
From my very limited experience, it looks to me like only two cogs are being used: cog(0) is by default the first launched (in PUB Start) and, without a cognew anywhere, PUB ServoControl is also run in cog(0). And cog(1) is called by FullDuplexSerial which is called by the XBee_Object's XB.start Method. Is that correct?
I think running the servos from their own cog would allow smoother movement. How would I start a cog just to control the servos?
Thanks,
falcon
Remote RX_12_04_2012 - Archive [Date 2012.12.04 Time 19.38].zip
I still think the following.
I added the rxflush after seeing it in the XBee tutorial code and Rforbes included in his examle from post # 15. I'll comment it out and see if it makes a difference. I'll leave it in there so I can check the difference with and without it as the code is developed further.
falcon
The servo movement smoothed only when the block of code that polls the TX for the RSSI and displays it is commented out. That continued transmission to the TX to check the RSSI seems to be causing the entire loop to lag.
How would I start a separate cog for the Servo Object? I think I'll have spare cogs. Or, perhaps the XBee and all of its RX and TX activity should be on a cog separate from the rest of the code. I plan to have data flowing both ways (telemetry from the bot) so the traffic will be heavier as this code develops.
falcon