GPS integration

[lalalandrus]

I know there is already a thread for GPS integration but the current solutions are softserial and or I2C.
Neither is a good solution:
1) SoftSerial uses interrupts which will can cause a huge bag of issues and quite intensive for the CPU
2) I2C requires special chips which translate the readily available serial to I2C

I propose the following: move the serial communications for the software GUI to the softserial library as when the GUI is connected, there is no need for intense computations so the limiation of point 1 is no an issue. The downside is that the GUI requires to use pins other than the serial header. The upside is that the TX/RX is now free to receive GPS NMEA strings through a robust hardware implementation.

If there are people that see the benefit to this, lets try to develop something and try to get it integrated into the main branch.

I have about 50 bare Trimble 1hz GPS chips that I am willing to share some with devs.

[PatrikE]

I have a suggestion how to do it.
I'm not intrested to se the Gui when i fly so i use a juperwire on one IO pin to disable the serial code for the gui.
At same time i change the serial to comunicate with GPS instead.

Just change the serialmode between GUI & GPS by changing the jumer.
I only check the mode at startup.

/Patik

[Loosi]

The idea with the jumper is great, but i think the problem we get then is later - when developing the waypoint mode:
it would be great when the waypoints can be transmitted "on the fly" via a wireless connection, i think then we have a problem


dont understand me false, but i think we have to see the other side: the version with the arduino promini is the "low cost version" for the people that only want to fly a bit and maybe want to use position hold and rtl. Then there is no need for a telemetry downlink.

If you want to do more (like using waypoint flying, maybe automatic takeoff and landing via sonar in the future and so on) you just have to choose another board with more capabilities like the flyduino mega.

[msev]

I would be perfectly happy just with RTH initiated when I enter failsafe, for fpv peace of mind hehe

[PatrikE]

I agree with you Loosi.
PROMINI and MEGA have different possiblilitys.
With a PROMINI and the jumper solution it's possible with Pre porgrammed route before takeoff. RTL & PosHold.

Mega can provide full optional Twoway Telemetry and all that.

[lalalandrus]

jumper idea is great, that way we can still upload the code without needing to reconnect different serial ports.

if we can prove that there is enough cpu cycles to perform soft serial, we can program the micro to send telemetry via RS232 to bluetooth (9 dollar items on ebay) on the soft serial pins whenever there is free execution time.

[babelo]

Hi,

About improving cpu time, it should be a better idea to just read one char or some char from serial line by loop
So after some loop the GPS string will be complete and one more loop later we decode it.
By this way , there is some gain improving the loop() for RC and sensors

[Loosi]

i think that should be possible if we do the check:
is the first char a $ and is the last char a <cr><lf>. i have some code for that on my external harddisk, i check it out if i can find it

[Alexinparis]

The idea is very interesting.
I've never thought about a serial soft for the GUI.
But currently, having the GUI and arduino IDE on the same port is very convenient. It won't be possible with this method.

[lalalandrus]

i agree that would be the down side, i think that if we do the jumper idea, the jumper is removed when you are ready to integrate into your system and thus the arduino IDE is no longer required...

edit: better yet, we can use a special char that the micro is expecting which is not found in typical NMEA strings. if this char is detected, then the GUI control is given, otherwise it expects input from GPS.....

edit2:

i think that should be possible if we do the check:
is the first char a $ and is the last char a <cr><lf>. i have some code for that on my external harddisk, i check it out if i can find it

sorry i didnt see this post but we are both on the same page

[Niclas Hedlund]

Hi everyone!
I'm very new to the MultiWii-code, but I'm working as firmware programmer, so coding isn't new to me.

Does the GUI ever send a '$' sign? (0x24)
This shouldn't be a problem since all NMEA-strings start with the '$' sign. (so we can use 0x24 as key for GPS-data)

If (received byte == '$') // GPS-data
{
// Parse the GPS-data
}
else // GUI-data
{
// Do the old GUI-code parsing
}

Do I miss anything major here?

Does the Rx routine wait for a "end of message" char before it start to parse the data? Or is everything just single-byte commands?

[PatrikE]

One problem is that Gps and Gui uses different Baudrates.

[Niclas Hedlund]

GUI uses 115200, right?

Many GPS units can select baudrate. That would solve the problem, but may be a "dirty" solution because it might not work with all GPS modules.

[Alexinparis]

Another problem: you do you ensure in this case the GUI TX commands won't interfere with the GPS TX commands ?
There would be nothing to "buffurise" bits

[lalalandrus]

use a 1k-10k feed resistor from the GPS into the Tx and the Rx pins, use the FTDI or equivalent cable without any feed resistors, the FTDI will overdrive the signal from the GPS.