GPS integration

copterrichie · Post by **copterrichie** » Wed Dec 12, 2012 8:44 pm

I was browsing YouTube and come upon this video. Seems someone has Waypoints working.

http://www.youtube.com/watch?v=WQ9t10BtYZI

EOSBandi · Post by **EOSBandi** » Wed Dec 12, 2012 9:17 pm

Yeah, implementing waypoint nav is not a big deal. BUT before that, we need a solid MAG and BARO implementation. I'm working on the MAG right now since the current calibration is a joke, and I saw some interesting movements on the BARO part too. Adding new features without making simple functions solid is for the Ardu guys...

copterrichie · Post by **copterrichie** » Wed Dec 12, 2012 9:21 pm

Glad you are Back.

alexia · Post by **alexia** » Wed Dec 12, 2012 10:00 pm

EOSBandi wrote:Yeah, implementing waypoint nav is not a big deal. BUT before that, we need a solid MAG and BARO implementation. I'm working on the MAG right now since the current calibration is a joke, and I saw some interesting movements on the BARO part too. Adding new features without making simple functions solid is for the Ardu guys...

i am FULLY agree with you
we have an example with ardu code..so many features but too many bugs..so nothing interessing! we need to move step by step

scrat · Post by **scrat** » Thu Dec 13, 2012 7:57 am

EOSBandi wrote:Yeah, implementing waypoint nav is not a big deal. BUT before that, we need a solid MAG and BARO implementation. I'm working on the MAG right now since the current calibration is a joke, and I saw some interesting movements on the BARO part too. Adding new features without making simple functions solid is for the Ardu guys...

@EOSBandi: what do you mean with "current cal. is a joke"? How will we then calibrate MAG with your code? Do you mean it will be no dancing?

EOSBandi · Post by **EOSBandi** » Thu Dec 13, 2012 8:53 am

Mag calibration is a threefold process.
1. normalize the gain on each axis
2. adjust the zero offsets for each axis.
3. compensate hard and soft iron disturbances.

Visually when you plot the x,y,z values from the mag (rotated on each axis) without calibration you will got a nice potato

After calibration this potato must become a perfect sphere.

In current code the gain normalization is faulty (wrong gain setting and not enough samples). The offset adjusting is more or less ok (this is the dance part). However it does not adjust the disturbances, so eventually you got an ellipsoid instead of a sphere.

I'm experimenting with the algorithm used in Fabio's FreeIMU_GUI program, which is a nice implementation of an ellipsoid to sphere transformation. I think we will need a separated program for calibration which will either write the data into eeprom or generate a .h file which could be included in the multiwii code.

So is will look like this :
1. load calibration program
2. do the dance, got visual feedback and you can decide that the calibration was successful or not.
3. Write a calibration.h file
4. load Multiwii
5. fly

dramida · Post by **dramida** » Thu Dec 13, 2012 8:59 am

Hello Eos, a while ago someone called Mahowik achived to control the variation of altitude with a P-D loop.

Here is the result http://www.youtube.com/watch?v=7Sa-oyJ4Ljs

The code used is in this archive:

download/file.php?id=1663

EOSBandi · Post by **EOSBandi** » Thu Dec 13, 2012 9:07 am

dramida wrote:Hello Eos, a while ago someone called Mahowik achived to control the variation of altitude with a P-D loop.

Here is the result http://www.youtube.com/watch?v=7Sa-oyJ4Ljs

The code used is in this archive:

download/file.php?id=1663

On step at a time... I saw some very promising baro code lately in the repo....

Crashpilot1000 · Post by **Crashpilot1000** » Thu Dec 13, 2012 11:32 am

@EOS Bandi: Improving the Mag is a terrific idea. Your approach seems to be a little bit too much action for the average user, but it is very reasonable. I am def. looking forward to this!
BTW: Did you risk an eye on my code? Is it pure crap or is there something of use? What is - from your experience - a safe delaytime between commands send to mtk without reading out it's returnmessage (@57KBaud). I am currently working with 1 sec...

Greetings
Kraut Rob

EOSBandi · Post by **EOSBandi** » Thu Dec 13, 2012 11:53 am

Crashpilot1000 wrote:@EOS Bandi: Improving the Mag is a terrific idea. Your approach seems to be a little bit too much action for the average user, but it is very reasonable. I am def. looking forward to this!
BTW: Did you risk an eye on my code? Is it pure crap or is there something of use? What is - from your experience - a safe delaytime between commands send to mtk without reading out it's returnmessage (@57KBaud). I am currently working with 1 sec...

Greetings
Kraut Rob

Perhaps it is too much, but this is the only way if we still want to use AtMega processors, the processing power is quite limited so sophisticated onboard algorithms are out of the question.

Regarding your code I took a quick look, not bad, I'll have to mix it with the ublox init which is quite sophisticated in the current multiwii_shared trunk. I would not wait more than 200ms between commands, that must be enough.

Crashpilot1000 · Post by **Crashpilot1000** » Thu Dec 13, 2012 5:08 pm

@EOS Bandi:
Hi!
Thank you very much for your reply!
I did another version. This time i improved the documentation in the maincode and config.h. Besides this i figured that a different minimum sat-count for different gps functions could be a good idea. PosHold is more a luxury feature so a higher satcount can be set. RTH is a more emergency function where a bigger error/lower satcount is OK. I made these variables accessible in the config.h

Code: Select all

#define MINSATPH 7                     // 5 is default minimal number of sats for gps PosHold, i found valid data with 7 sats. Since PH is luxury we want more sats..
#define MINSATRTH 5                    // 5 is default minimal number of sats for gps Return to Home since this is more an emergency function a 20m error doesn't matter

Concerning the MTK Binary mode i activated everything beneficial i could find. The most of it will be probably already on. The delay between commands is still set to 500 ms

.....
The simple spikefilter seems to be very usable on 5Hz data.
Keep up your outstanding work !!!

Cheers

Kraut Rob

Crashpilot1000 · Post by **Crashpilot1000** » Thu Dec 13, 2012 8:16 pm

Oops ! Something went wrong. Test03 is better than test04 i am not sure if it is the modified ini sequence for the mtk or the satcount thing.

EOSBandi · Post by **EOSBandi** » Thu Dec 13, 2012 11:36 pm

I just committed some rework on the HMC5883L gain calibration (init). The code is based on Fabio's FreeIMU code and I think this is as good now as it could be on this platform. After some experimenting I decided to keep the current offset calibration method (MAG DANCE) since the ellipsoid to sphere method did not gave significantly better results, but added difficulty to the calibration process. I tested it but i would appriciate if somebody will took a look.

vpb · Post by **vpb** » Fri Dec 14, 2012 2:14 am

Hi EOSBandi, I see your new commit on latest r1284 dev. "No changes in the mag calibration dance, gain calibration is done automatically
at every startup". I want to test that new MAG calibration code, does the procedure change?

Thank you!

doppler · Post by **doppler** » Fri Dec 14, 2012 3:42 am

EOSBandi wrote:I just committed some rework on the HMC5883L gain calibration (init). The code is based on Fabio's FreeIMU code and I think this is as good now as it could be on this platform. After some experimenting I decided to keep the current offset calibration method (MAG DANCE) since the ellipsoid to sphere method did not gave significantly better results, but added difficulty to the calibration process. I tested it but i would appriciate if somebody will took a look.

Trying it now, seems fine, I didn't do any additional calibrations or anything, is there something special needed?

I do have a question about the magnometer it may be specific to the HMC5883L (I don't have any other ones). On a flat surface I have it indicating north when the IMU is pointing north, and when I spin the IMU around the indicator points correctly due to that spin. So far so good. But if I angle the board (pitch or roll), any amount, and hold the board in all other directions the compass starts to head elsewhere, this is best demonstrated when pointing the board East or West. I was playing with Headhold today (build 1240) and was watching my quad yaw every time i took it off being level to go in a direction, as you would expect from my description, the quad didn't go where it was supposed to. Left the quad level itself again (Angle mode on) and the quad returns to the direction I had it held too..... this seems to me to make mag hold, useless, I suspect headfree would be just as useless. Shouldn't there be some fancy math involving the ACC and/or GYRO's so that the X, Y, and Z are used to offset the changes the mag is experiencing?

I would expect this to completely break when doing flips, so I would only think it should work when MAG and ANGLE are used for instance.

crashlander · Post by **crashlander** » Fri Dec 14, 2012 8:58 am

Hello EOSBandi!
Nice to have you back.

Regarding baro code...

EOSBandi wrote:On step at a time... I saw some very promising baro code lately in the repo....

...that last published (and than removed but accessible as zip in forum) code from Mahovik actually works very good (and at least in my case stable) but I believe it is not included in official _shared. And since it includes variometric (constant speed) climb and descend based on TH stick offset from set-point it is probably very good start into GPS point to point navigation.

Best Regards
Andrej

fax8 · Post by **fax8** » Fri Dec 14, 2012 10:15 am

I also saw the magnetometer calibration implemented by EOSBandi .. while that is surely better than before, you should really have a look at my new code for ellipsoid into sphere approximation.. check out the FreeIMU GUI: http://www.varesano.net/blog/fabio/free ... ersion-out
It's been discussed also here but people didn't seem much interested.. viewtopic.php?f=8&t=2175

Ideally, the FreeIMU GUI code has been written with the idea of supporting different serial protocols.. so far it only supports the FreeIMU library code, but adding support for the MultiWii shouldn't be difficult.

EOSBandi · Post by **EOSBandi** » Fri Dec 14, 2012 12:37 pm

fax8 wrote:I also saw the magnetometer calibration implemented by EOSBandi .. while that is surely better than before, you should really have a look at my new code for ellipsoid into sphere approximation.. check out the FreeIMU GUI: http://www.varesano.net/blog/fabio/free ... ersion-out
It's been discussed also here but people didn't seem much interested.. viewtopic.php?f=8&t=2175

Ideally, the FreeIMU GUI code has been written with the idea of supporting different serial protocols.. so far it only supports the FreeIMU library code, but adding support for the MultiWii shouldn't be difficult.

Hi Fabio,
I spent quite a time and even implemented a calibration using calibration.h from FreeIMU GUI. At the end of the day, it seemed to me that the outcome was not significantly different from results of the current offset calibration method. I admit that the current method does not address soft iron distorsions, but the question is that do we really need soft iron calibration ? Or with the current precision of the other elements of MultiWii it is just fine...

BTW, my gain calibration code is vastly based on your code, so credits goes to you !

EOS

shikra · Post by **shikra** » Fri Dec 14, 2012 3:47 pm

Hi - very quick drop in as been tied up with new job...

FWIW, I think the current Mag calib is good enough for what we need - other bits need improving first really.

What I have noticed is that if the copter is moved correctly during calib it makes abig difference. Smooth mag readings as rotate, rather than fast in some directions and slow in others. Also less deviation when copter is tilted.

In hold/RTH, I've not really seen any issues due to mag deviation.

Crashpilot1000 · Post by **Crashpilot1000** » Fri Dec 14, 2012 7:56 pm

Help!

Sorry to interrupt here, but i am still struggeling with the MTK 3329 module the AXN1.51_2722_3329_384.1151100.5.bin and a valid DGPS fix. I connected the modul directly (via FTDI) to realterm (very good tip - thanks to EOS Bandi

) and let it put out NMEA strings (not turned to binary mode) at just 1Hz and observed the GGA strings. I got 10 Sats but never a DGPS fix. I threw every command at it that could possibly activate waas/sbas - nothing. Has anyone DGPS fix running on a binary capable Firmware?
Any help would be very appreciated!
Probably some simple methodical error?

Cheers

Kraut Rob

List of acknowledged commands but without success:

Code: Select all

  #define MTK_SBAS_INTEGRITYMODE"$PMTK319,1*24\r\n"    // TEST:ACK 
  #define MTK_NAVTHRES_OFF      "$PMTK397,0*23\r\n"    // TEST:ACK Threshold was 1.00m before (PMTK447 returns 0.0 NOW)
  #define MTK_SBAS_ON      "$PMTK313,1*2E\r\n"    // Enable search SBAS sat // TEST:ACK
  #define MTK_WAAS_ON           "$PMTK301,2*2E\r\n"    // DGPS MODE WAAS // TEST:ACK

List of commands described in the A11 revision of the MTK commandset but returned "ERROR UNSUPPORTED COMMAND"

Code: Select all

  #define MTK__DT_NAVTHRES_OFF  "$PMTK527,0.00*00\r\n" // Turn off Navthreshold // TEST: ERROR UNSUPPORTED COMMAND
  #define MTK__DT_NAVTHRES_OFF  "$PMTK527,0*2E\r\n" // Turn off Navthreshold // TEST: ERROR UNSUPPORTED COMMAND
  #define MTK_DT_SBAS_ENABLED   "$PMTK513,1*28\r\n"  // Enable Search for SBAS Sats // TEST: ERROR UNSUPPORTED COMMAND
  #define MTK_DT_DGPS_WAAS      "$PMTK501,2*28\r\n"  // DGPS data source mode: WAAS // TEST: ERROR UNSUPPORTED COMMAND

EOSBandi · Post by **EOSBandi** » Fri Dec 14, 2012 9:45 pm

To get SBAS (actually EGNOS in Europe) you have to see one of the following sats : 120, 124, 126. Sat number 124 is in usually in test mode. So you have to enable using of test mode packets with $PMTK319,0*25<CR><LF>. sat 120 and 126 should work in integrity mode.

My recommendation is still that you should abandon MTK3329 and get a Ublox. The config and diag software is better by lighthyears than miniGPS.

Crashpilot1000 · Post by **Crashpilot1000** » Fri Dec 21, 2012 1:09 am

Hi!
3drobotics just released a new firmware for MTK 3329 it is called 1.9 or "AXN1.51_2776_3329_384.1151100.5_v19.bin". You can grab it here: http://code.google.com/p/ardupilot-mega ... n&can=2&q=

This FW 1.9 responds in binary mode with one decimal more precision(!)than current mtk binary or nmea and has therefor an altered syncword.
I added a slightly modified I2C_GPS_NAV-v2.1rc2 from EOS Bandi (http://code.google.com/p/i2c-gps-nav/do ... p&can=2&q=). The config.h is already set to go for mtk binary with the FW 1.9 mentioned above. It is not compatible to the old mtk binary firmwares. In the config.h you will come across my spikefilter wich i find very useful, but you can deactivate it there. You can also alter the minimum sats required for gps functions there. You can now /will have to increase the "P" of your current GPS Pids.

Cheers

Kraut Rob

EOSBandi · Post by **EOSBandi** » Fri Dec 21, 2012 9:37 am

Crashpilot1000 wrote:Hi!
3drobotics just released a new firmware for MTK 3329 it is called 1.9 or "AXN1.51_2776_3329_384.1151100.5_v19.bin". You can grab it here: http://code.google.com/p/ardupilot-mega ... n&can=2&q=

This FW 1.9 responds in binary mode with one decimal more precision(!)than current mtk binary or nmea and has therefor an altered syncword.
I added a slightly modified I2C_GPS_NAV-v2.1rc2 from EOS Bandi (http://code.google.com/p/i2c-gps-nav/do ... p&can=2&q=). The config.h is already set to go for mtk binary with the FW 1.9 mentioned above. It is not compatible to the old mtk binary firmwares. In the config.h you will come across my spikefilter wich i find very useful, but you can deactivate it there. You can also alter the minimum sats required for gps functions there. You can now /will have to increase the "P" of your current GPS Pids.

Cheers

Kraut Rob

One significant note. GlobalTop firmwares (which is used by 3Dr) are vendor protected from version 1.5 and up. This means that you can upload this firmware only to a Pa6B or other Global-Top made MT3329 chip based modules.

I'll incorporate Rob's changes during the festive season.

Crashpilot1000 · Post by **Crashpilot1000** » Sat Dec 22, 2012 2:00 am

Thank you very much for being so active, supportive and helpful all the time in your scarce free time!
Since apm is struggeling with their autodetection code (confusion starts here: http://diydrones.com/xn/detail/705844:Comment:1062391) it may be an idea to make the mtk binary support depending on firmware selectable in the config.h. So the user should know what FW is running on his mtk3329 gps (running MiniGPS will give him clarification of that) a fw before 1.9 or 1.9 and define it in config.h. Mwii users got more guts

- i guess. My C/Arduino Coding abilities are very limited, i just coded on my purely loved Amiga1000 some Demos 22 years ago, so i am definately not the person to give you any coding advice at all. BUT i am very excited about your work on 2.2 of your gps code!

Since the world didn't destroy itself already I want to wish you and your family a very happy christmas!

Yours
Kraut Rob

dramida · Post by **dramida** » Wed Dec 26, 2012 11:48 am

EOSBandi wrote:I just committed some rework on the HMC5883L gain calibration (init). The code is based on Fabio's FreeIMU code and I think this is as good now as it could be on this platform. After some experimenting I decided to keep the current offset calibration method (MAG DANCE) since the ellipsoid to sphere method did not gave significantly better results, but added difficulty to the calibration process. I tested it but i would appriciate if somebody will took a look.

Hi Eos, just uploaded the code on the controller, i'll calibrate it on the field and then fly it on PosHold. I''ll give the results later in the evening.
/Mihai

EOSBandi · Post by **EOSBandi** » Thu Dec 27, 2012 12:42 am

Hi Folks,
I just committed an update to the GPS parsers. it includes :
- updated initialisation for MTK gps modules correct EGNOS init and set navigation threshold (Thanks for Crashlander for the help and test)
- Added MTK binary protocol for both versions of DiyDrones binary MTK firmwares (v1.6 (AXN1.3-2389) and v1.9(AXN1.51-2776)) (Thanks again to Crashlander for notify me about the new fw)
- Added a forward predictive filter to gps position calculation, which eliminates the gps lag. (based on the code from Jason Short)

Due bad weather it is only tested on the desk, so please use it wisely.

albertoLG · Post by **albertoLG** » Thu Dec 27, 2012 9:01 am

EOSBandi wrote:Hi Folks,
I just committed an update to the GPS parsers. it includes :
- updated initialisation for MTK gps modules correct EGNOS init and set navigation threshold (Thanks for Crashlander for the help and test)
- Added MTK binary protocol for both versions of DiyDrones binary MTK firmwares (v1.6 (AXN1.3-2389) and v1.9(AXN1.51-2776)) (Thanks again to Crashlander for notify me about the new fw)
- Added a forward predictive filter to gps position calculation, which eliminates the gps lag. (based on the code from Jason Short)

Due bad weather it is only tested on the desk, so please use it wisely.

uumm... updated my gps firmware to "AXN1.51_2776_3329_384.1151100.5_v19.bin", EOSBandi, tested your revision, gps show in the gui and the leds flash so i have a 3Dfix, but seems more unstable than previous revision I used... with the previous when I switched to PH the quad just was in position with no big swings... now it just go away, try to go back but with big error in position... like was without changing my threshold settings

EDIT:
tested again and seems better now... probably was a poor satellite reception, first test was with very cloudy sky... second test with no clouds... poor MTK antenna? overall... fast 3Dfix than previously and better position and nav (tested a couple of RTH, ah.... wobble a little too much in navigation, need probably to tune PID, I use defaults)

EOSBandi · Post by **EOSBandi** » Thu Dec 27, 2012 9:24 am

Try to comment out the gps_lead_filter define in config, see if it is the gps or the filter. Also try 4hz updaate rate...

albertoLG · Post by **albertoLG** » Thu Dec 27, 2012 9:27 am

EOSBandi wrote:Try to comment out the gps_lead_filter define in config, see if it is the gps or the filter. Also try 4hz updaate rate...

edited my post when you were writing yours.. :-)

I'll do this test also to see if change something

dramida · Post by **dramida** » Thu Dec 27, 2012 10:37 am

EOSBandi wrote:Hi Folks,
I just committed an update to the GPS parsers. it includes :
- updated initialisation for MTK gps modules correct EGNOS init and set navigation threshold (Thanks for Crashlander for the help and test)
- Added MTK binary protocol for both versions of DiyDrones binary MTK firmwares (v1.6 (AXN1.3-2389) and v1.9(AXN1.51-2776)) (Thanks again to Crashlander for notify me about the new fw)
- Added a forward predictive filter to gps position calculation, which eliminates the gps lag. (based on the code from Jason Short)

Due bad weather it is only tested on the desk, so please use it wisely.

Great work Eos

I'll test it along with the new mag calibration procedure and Adrian new altitudevario implementatio viewtopic.php?f=8&t=2371&p=28353#p28352

The Christmas presents are coming later this year

jaames74 · Post by **jaames74** » Thu Dec 27, 2012 1:15 pm

EOSBandi wrote:Hi Folks,
I just committed an update to the GPS parsers. it includes :
- updated initialisation for MTK gps modules correct EGNOS init and set navigation threshold (Thanks for Crashlander for the help and test)
- Added MTK binary protocol for both versions of DiyDrones binary MTK firmwares (v1.6 (AXN1.3-2389) and v1.9(AXN1.51-2776)) (Thanks again to Crashlander for notify me about the new fw)
- Added a forward predictive filter to gps position calculation, which eliminates the gps lag. (based on the code from Jason Short)

Due bad weather it is only tested on the desk, so please use it wisely.

hi Eos,
will you make this update available for "poor" I2C GPS users like me?? :lol:

EOSBandi · Post by **EOSBandi** » Thu Dec 27, 2012 1:33 pm

jaames74 wrote:hi Eos,
will you make this update available for "poor" I2C GPS users like me??

Stay tuned it is on it's way....

dramida · Post by **dramida** » Thu Dec 27, 2012 4:09 pm

I just flew R1292 with GPS prediction filter and new mag calibration routine. I am using Crius AIOP with Ublos Neo 6M binary protocol GPS.
In my opinion the positioning is twice as better than previous as i could stay on GPS PH on a narrow street between buildings.
Anyway i made a test with my 1050 mm tricopter in witch i flew from take-of to landing in position hold.
Here is the video:
http://www.youtube.com/watch?v=2GpTA8-glQs
One aspect to mention: when yaw-ing in PH, the copter makes big circles but smaller than previous algorithm.

jaames74 · Post by **jaames74** » Thu Dec 27, 2012 4:53 pm

dramida wrote:I just flew R1292 with GPS prediction filter and new mag calibration routine. I am using Crius AIOP with Ublos Neo 6M binary protocol GPS.
In my opinion the positioning is twice as better than previous as i could stay on GPS PH on a narrow street between buildings.
Anyway i made a test with my 1050 mm tricopter in witch i flew from take-of to landing in position hold.
Here is the video:
http://www.youtube.com/watch?v=2GpTA8-glQs
One aspect to mention: when yaw-ing in PH, the copter makes big circles but smaller than previous algorithm.

does this test video include nhardians' s ALTHOLD mate??

dramida · Post by **dramida** » Thu Dec 27, 2012 5:13 pm

No, that Alt Vario test with Adrian's software is scheduled tomorrow, the day is too short

But as you well noticed, there is a basic Alt Vario implementation also in R1298 software. I have to test Adrian's more featured altitude mod before making a judgement about altitude vario implementation.

EOSBandi · Post by **EOSBandi** » Fri Dec 28, 2012 9:18 pm

Hi Folks,

i2c-gps-nav v2.2beta1 is just released for testing!
you can get it from : http://code.google.com/p/i2c-gps-nav/downloads/list

New features :
MTK Binary protocol 1.9 (from DIYDrones)
UBLOX init
MTK init
Lead predictive filtering (updated)
SONAR handling (See config.h for more info)

This is the first beta release, is sould work with MW 2.1 and recent devs BUT there will be some upcoming fixes which will impact data structures so the final I2C-V2.2 release will work only with MW 2.2 (or a TBD revision from SVN)

Disclaimer : Since I don't see a penny from third party manufacturers i2cgps board versions, i cannot provide support for such boards. The primary supported platform for I2C-GPS-NAV is a pure vanilia arduino mini or nano with direcly attached GPS and sonar modules.

dramida · Post by **dramida** » Fri Dec 28, 2012 9:35 pm

I am very happy with curent Ublox 6M gps predictive filter-mag calibration implementation, way better than last dev version, good work Mr. Eos

wilco1967 · Post by **wilco1967** » Fri Dec 28, 2012 9:47 pm

Hi

tried the new version 1298 by EosBandi on a Flyduino Mega with a flyduino FMP03 / 3329 GPS

got it working in binary mode using the 1.6 firmware (AXN1.30_2389_3329_384.1151100.1_v16.bin), but no succes in using the 1.9 firmware (AXN1.51_2776_3329_384.1151100.5_v19.bin).

update of GPS with 1.9 firmware was succesful, however it does not seem to send anything other than the same line over and over again.
Also it does not seem to respond to configuration command being sent (to which the 1.6 firmware responded correctly)...

in an earlier post it was mentioned that

This means that you can upload this firmware only to a Pa6B or other Global-Top made MT3329 chip based modules.

.....

So I assume this is the problem I'm facing.... but what I don't understand is, what makes a flyduino 3329 based GPS any different from others ?

With the 1.6 firmware, could not observe anything different than previously using NMEA on MTK3329_A1.5E_20110118_10Hz_115200.bin

EOSBandi · Post by **EOSBandi** » Fri Dec 28, 2012 10:20 pm

The vendor ID which is set in the module.
PA6B made by Global-Top, and they wrote the 1.9 firmware
FMP04 made by FTech and they did not wrote any firmware

A1.5E is an NMEA only firmware.... the latest fw for your module is the 1.3-(v1.6) for binary mode. (it also made by Global-Top but did not check for vendor ID)

Sharkcopter · Post by **Sharkcopter** » Fri Dec 28, 2012 10:43 pm

I am very saddened to tell you that Fabio Varesano, the manufacturer of FreeImu died on Christmas Day.
He was only 27 years of age.
This morning we attended his funeral.
I remember him as a friend with a great desire to try and help others.

EOSBandi · Post by **EOSBandi** » Fri Dec 28, 2012 10:48 pm

Sharkcopter wrote:I am very saddened to tell you that Fabio Varesano, the manufacturer of FreeImu died on Christmas Day.
He was only 27 years of age.
This morning we attended his funeral.
I remember him as a friend with a great desire to try and help others.

OMG ! I'm shocked. Please forward my condolences. The community will miss him.

alexia · Post by **alexia** » Sat Dec 29, 2012 2:12 am

Sharkcopter wrote:I am very saddened to tell you that Fabio Varesano, the manufacturer of FreeImu died on Christmas Day.
He was only 27 years of age.
This morning we attended his funeral.
I remember him as a friend with a great desire to try and help others.

it s so sad......it s so young to died :cry:

how it s possible?it was sick?

diyboy · Post by **diyboy** » Sat Dec 29, 2012 4:46 am

Sharkcopter wrote:I am very saddened to tell you that Fabio Varesano, the manufacturer of FreeImu died on Christmas Day.
He was only 27 years of age.
This morning we attended his funeral.
I remember him as a friend with a great desire to try and help others.

it s so sad.........! :cry:

Sharkcopter · Post by **Sharkcopter** » Sat Dec 29, 2012 10:58 am

alexia wrote:
Sharkcopter wrote:I am very saddened to tell you that Fabio Varesano, the manufacturer of FreeImu died on Christmas Day.
He was only 27 years of age.
This morning we attended his funeral.
I remember him as a friend with a great desire to try and help others.

it s so sad......it s so young to died
how it s possible?it was sick?

No he was not sick, a cerebral infarction.

wilco1967 · Post by **wilco1967** » Sat Dec 29, 2012 11:25 am

Sharkcopter wrote:I am very saddened to tell you that Fabio Varesano, the manufacturer of FreeImu died on Christmas Day.
He was only 27 years of age.
This morning we attended his funeral.
I remember him as a friend with a great desire to try and help others.

What to say more.....
My deepfelt condolances....

mahowik · Post by **mahowik** » Sat Dec 29, 2012 5:36 pm

Sharkcopter wrote:I am very saddened to tell you that Fabio Varesano, the manufacturer of FreeImu died on Christmas Day.
He was only 27 years of age.
This morning we attended his funeral.
I remember him as a friend with a great desire to try and help others.

Shocked!!! It's very strange, but very often when best people are died so young... it's very very sad... 27 years... ((((

jevermeister · Post by **jevermeister** » Sat Dec 29, 2012 5:38 pm

damn...

my condolences to family and friends...

dramida · Post by **dramida** » Sat Dec 29, 2012 7:03 pm

Wellcome back Mahowik aka Alex.

We'll miss Fabio.
I propose a few words in credits.txt about the generosity of Fabio Vanessano.
Fabio, now you are free to fly where only your imagination could go from this earth.
/Mihai

alexia · Post by **alexia** » Sun Dec 30, 2012 1:21 am

dramida wrote:Wellcome back Mahowik aka Alex.

We'll miss Fabio.
I propose a few words in credits.txt about the generosity of Fabio Vanessano.
Fabio, now you are free to fly where only your imagination could go from this earth.
/Mihai

fully agree with that

Sharkcopter · Post by **Sharkcopter** » Sun Dec 30, 2012 10:43 am

Sharkcopter wrote:I am very saddened to tell you that Fabio Varesano, the manufacturer of FreeImu died on Christmas Day.
He was only 27 years of age.
This morning we attended his funeral.
I remember him as a friend with a great desire to try and help others.

I apologize for the announcement.
I came just now aware, through an Italian forum, that the Fabio family has no pleasure of commemorations on the forums that he frequented.
We respect their wishes.