2-way com with aurdu with GPS and in auto
I have just perfected (finally got to work) a method for sending data up to the plane while in auto and without missing a GPS frame. I've been using all my spare time for a week to get it.
It works by sharing the uart time wise. The U-blox sends data for ~28ms 4X /s. That leaves a lot of time to receive from the X-bee. The X-bee has a 256 byte buffer the will hold data until the ardu asks for it.
If the RTS(request to send) is not connected the data goes right through. If the RTS is held HIGH. the X-bee will hold the data packet until RTS goes LOW. Packets must be less than 256 bytes. No problem!
I connected the RTS to D7 on the ardu and the Tx from the X-bee goes to a diode to the ardu. Basiclly two diodes pointing away from each other and a 10 K pull up resistor. The cathode of the other diode goes to the GPS Tx. The middle goes to the ardu Rx. After the data is read from the GPS and the extra bytes in the 368 uart buffer are cleared (read and dumped), D7 is set low and the X-bee sends received data to the ardu, when that's done D7 goes HIGH again. I used Jordi's "decode" from the GS
in the ardu to read and process the received data. BTW I have a pretty good dual trace scope that I used to see what was going on. Impossible to debug without one. Will post more details and code later.I just now got it to work and have something I got to do right now. And I'am not using the shield, but it should work with one.
Update: This is a re-post of yesterdays topic, but under the right category.
Today I got it working without hoseing the UBLOX nav data. I was going into my read function after each UBLOX id. I think the UBLOX sends the entire class all at once and each id has its own chechsum. I forced the function to keep going until all the id fields used are read, then go on and read the X-bee. The stock version reads an id field and moves on and at the next call to it gets the next id end so on. After each id read I was dumping the rest of the needed data except for the nav_status I think. With this flaw I never lost the blue lock led, just got all zeros for the data or the data froze as is. After some more thurough testing/de-bugging I will post the code modifications if any one is interested.
It works by sharing the uart time wise. The U-blox sends data for ~28ms 4X /s. That leaves a lot of time to receive from the X-bee. The X-bee has a 256 byte buffer the will hold data until the ardu asks for it.
If the RTS(request to send) is not connected the data goes right through. If the RTS is held HIGH. the X-bee will hold the data packet until RTS goes LOW. Packets must be less than 256 bytes. No problem!
I connected the RTS to D7 on the ardu and the Tx from the X-bee goes to a diode to the ardu. Basiclly two diodes pointing away from each other and a 10 K pull up resistor. The cathode of the other diode goes to the GPS Tx. The middle goes to the ardu Rx. After the data is read from the GPS and the extra bytes in the 368 uart buffer are cleared (read and dumped), D7 is set low and the X-bee sends received data to the ardu, when that's done D7 goes HIGH again. I used Jordi's "decode" from the GS
in the ardu to read and process the received data. BTW I have a pretty good dual trace scope that I used to see what was going on. Impossible to debug without one. Will post more details and code later.I just now got it to work and have something I got to do right now. And I'am not using the shield, but it should work with one.
Update: This is a re-post of yesterdays topic, but under the right category.
Today I got it working without hoseing the UBLOX nav data. I was going into my read function after each UBLOX id. I think the UBLOX sends the entire class all at once and each id has its own chechsum. I forced the function to keep going until all the id fields used are read, then go on and read the X-bee. The stock version reads an id field and moves on and at the next call to it gets the next id end so on. After each id read I was dumping the rest of the needed data except for the nav_status I think. With this flaw I never lost the blue lock led, just got all zeros for the data or the data froze as is. After some more thurough testing/de-bugging I will post the code modifications if any one is interested.
- Attachments:
-
-
Com connect.bmp, 729 KB
-
Replies to This Discussion
-
Permalink Reply by Magnus Persson on -
hi
2-way com does this also with the EM-406A? or is it just ublox that works?
is there anyone who got it to work with EM-406A? if so how?
thanks in advance
Magnus
-
Permalink Reply by Greg Fletcher on -
Yes it would. I developed this with the ublox ,but worked with the 406 when I was honing my skills(ie. trying to figer out how it works)I just haven't done it yet, but it should be relatively easy.
-
Permalink Reply by Jean-Louis Naudin on -
Hello Earl,
Below you will find a table about the Lipo (3S, 11,1V) % of charge Vs the Voltage, it seems interesting to better show the charge % of the battery than the voltage. The only thing to do is to put the throttle to 0 before reading the %
Regards
Jean-Louis
-
Permalink Reply by Earl on -
I have also considered this $75 board that has a parallax propeller bhip aome a/d and digi in/out. Piggy back an XBee and think what we can do !'
Ear; - Attachments:
-
-
Cheese.jpg, 657 KB
-
-
Permalink Reply by Earl on
-
bitmap came in fine..
Here is a parallax propeller chip with a 3x3 screen you can origram woth text, pics anything..only costs $75 and put an xbee on it and it would make a good G/S with color. Also has SD card slot for data logging.
Earl - Attachments:
-
-
Cheese.jpg, 657 KB
-
-
Permalink Reply by Earl on
-
Hi Greg,
Hope you have some more time to pursue this. I am now boxing up my ArduStation.
Earl
-
Permalink Reply by Nick Sargeant on -
Greg, have you gotten any further with this?
-
Permalink Reply by Greg Fletcher on
-
Nick, I have it working very good now. The hard ware works very well. I have been buisy adding code to the Ardustation and Ardupilot This has been an amazing learning experience for me. Kind of like learn as you go and I can write code a lot faster than when I started. I previousely had very little programing experience(CS101). Any how there is a lot of integration between the Astation and the AP. I have added a lot of features that don't even need the uplink, like a low battery alert with auto cell # detection, GPS and AP mode status change alert, WP change alert, and I can add more pretty quick now. As for uplink I have roll, pitch, heading PI gains. It is very reliable using checksums and replies for the uplinked data. It took a lot of testing and trouble shooting to get it working reliably. I have a google code page with a wiki. I will be uploading latest version this weekend. The version up there now has some minor bugs and shouldnt be used. It has not been flight tested yet, but its basicaly vesion 2.4 as is with a lot of stuff added. You will need a custom board like mine or the V2 sheild and a couple of extra wires.
Oh and I got it working with the EM406 and it will even work with the GPS off.
I haven't had any feed back from others I had test it, but its working good for me.
Watch this space.
.
-
Permalink Reply by Earl on
-
Hi Greg,
Sorry I have not had time to get back to you but my trip to Haiti has taked over everything for a while. I will keep you informed.
Keep up the great work.
Earl
-
Permalink Reply by Mark Colwell on -
Could you please post a link to your wiki when 2_way code is ready. I will be testing this in several configurations with various IMUs Thanks..
- ‹ Previous
- 1
- 2
- Next ›
Top Content
Groups
-
ArduCopter User Group
478 members
-
ArduPlane User Group
299 members
-
ArduCopter (traditional …
77 members
-
ArduPilot (legacy) User …
77 members
-
Moderators
50 members
-
ROS User Group
31 members
-
Team Prometheus
11 members
© 2012 Created by Chris Anderson.
