GPS integration
- NikTheGreek
- Posts: 348
- Joined: Thu Dec 08, 2011 4:17 pm
- Location: Greece
- Contact:
Re: GPS integration
Thank you Gimbal.
Done it....
but now i cant take any readings in MiniGps.
Done it....
but now i cant take any readings in MiniGps.
-
- Posts: 244
- Joined: Sat Mar 23, 2013 12:34 am
- Location: Australia
Re: GPS integration
A discussion with Crashpilot1000 over in the 32bit harakiri thread and in the #multiwii IRC has highlighted an issue with the GPS init strings, specifically relating to SBAS, GPS Augmentation, namely its location specific.
Currently, if you have a MTK gps and INIT_MTK_GPS is defined, it automatically forces SBAS to WAAS (which is in the USA). If you have UBLOX defined, it automatically configures the GPS (no user selectable INIT_BLOX_GPS define as per MTK) SBAS to EGNOS (which is Europe). At least according to the comments...
No location specific configuration should be pushed to GPS (or should be user selectable given the correct region), and automatic GPS Configuration should always be user selectable in config.h. especially since UBLOX EEPROM equipped GPS modules became available. RFC.
Currently, if you have a MTK gps and INIT_MTK_GPS is defined, it automatically forces SBAS to WAAS (which is in the USA). If you have UBLOX defined, it automatically configures the GPS (no user selectable INIT_BLOX_GPS define as per MTK) SBAS to EGNOS (which is Europe). At least according to the comments...
No location specific configuration should be pushed to GPS (or should be user selectable given the correct region), and automatic GPS Configuration should always be user selectable in config.h. especially since UBLOX EEPROM equipped GPS modules became available. RFC.
Re: GPS integration
Wrong.
Enabling SBAS automatically enables WAAS and EGNOS plus all other working augmenting methods. There is no different command to enable EGNOS or WAAS. The only difference is that WAAS and EGNOS uses different PRN's to broadcast augmentation data but once SBAS is enabled, the GPS will look for ANY PRN's that provide this data. The only thing that you can add is to enable SBASB PRN's that usually provide data in test mode (This is PRN124).
So the init strings are OK for MTK in the current code and they are NOT geodependent.
Defines are indeed missleading.
#define SBAS_ON PSTR("$PMTK313,1*2E\r\n") //Enable SBAS
#define WAAS_ON PSTR("$PMTK301,2*2E\r\n") // Set DGPS source to SBAS
However i just checked the ublox init string and it seems totally wrong for me to enable SBAS....
Enabling SBAS automatically enables WAAS and EGNOS plus all other working augmenting methods. There is no different command to enable EGNOS or WAAS. The only difference is that WAAS and EGNOS uses different PRN's to broadcast augmentation data but once SBAS is enabled, the GPS will look for ANY PRN's that provide this data. The only thing that you can add is to enable SBASB PRN's that usually provide data in test mode (This is PRN124).
So the init strings are OK for MTK in the current code and they are NOT geodependent.
Defines are indeed missleading.
#define SBAS_ON PSTR("$PMTK313,1*2E\r\n") //Enable SBAS
#define WAAS_ON PSTR("$PMTK301,2*2E\r\n") // Set DGPS source to SBAS
However i just checked the ublox init string and it seems totally wrong for me to enable SBAS....
-
- Posts: 244
- Joined: Sat Mar 23, 2013 12:34 am
- Location: Australia
Re: GPS integration
Okay, that's good then.. indeed, the comments and defines are misleading. Ability to selectively enable SBAS or/and bypass config/init strings being pushed to ublox GPSes, similar to the INIT_MTK_GPS define, is something that should be amended.
Several other UAV codebases seem to recommend disabling SBAS and u-blox has this to say about it:
"Ionospheric corrections such as those received from local SBAS geostationary satellites (WAAS, EGNOS, MSAS) or from GPS enable the highest positioning accuracy with the PPP algorithm. The maximum improvement of positioning accuracy is reached with PPP+SBAS and can only be expected in an environment with unobstructed sky view during a period in the order of minutes." Potentially leading to a shift in GPS position after a few minutes (potentially mid flight) if a relevant SBAS source is available.
Several other UAV codebases seem to recommend disabling SBAS and u-blox has this to say about it:
"Ionospheric corrections such as those received from local SBAS geostationary satellites (WAAS, EGNOS, MSAS) or from GPS enable the highest positioning accuracy with the PPP algorithm. The maximum improvement of positioning accuracy is reached with PPP+SBAS and can only be expected in an environment with unobstructed sky view during a period in the order of minutes." Potentially leading to a shift in GPS position after a few minutes (potentially mid flight) if a relevant SBAS source is available.
Re: GPS integration
felixrising wrote:Okay, that's good then.. indeed, the comments and defines are misleading. Ability to selectively enable SBAS or/and bypass config/init strings being pushed to ublox GPSes, similar to the INIT_MTK_GPS define, is something that should be amended.
Indeed.
felixrising wrote:Several other UAV codebases seem to recommend disabling SBAS and u-blox has this to say about it:
"Ionospheric corrections such as those received from local SBAS geostationary satellites (WAAS, EGNOS, MSAS) or from GPS enable the highest positioning accuracy with the PPP algorithm. The maximum improvement of positioning accuracy is reached with PPP+SBAS and can only be expected in an environment with unobstructed sky view during a period in the order of minutes." Potentially leading to a shift in GPS position after a few minutes (potentially mid flight) if a relevant SBAS source is available.
Nope, this is about PPP, not normal GPS navigation.
- Crashpilot1000
- Posts: 631
- Joined: Tue Apr 03, 2012 7:38 pm
Re: GPS integration
@EOS Bandi:
Hi!
Is there already an consent/agreement what the final multiwii - WP standard would look like? Will that be the final: http://code.google.com/p/multiwii/sourc ... al.ino#487? Why not 16Bit altitude in m? What further CHECKBOXITEMS are planned? I just ask, to keep my code compatible in that area to mwii.
Cheers
Rob
Hi!
Is there already an consent/agreement what the final multiwii - WP standard would look like? Will that be the final: http://code.google.com/p/multiwii/sourc ... al.ino#487? Why not 16Bit altitude in m? What further CHECKBOXITEMS are planned? I just ask, to keep my code compatible in that area to mwii.
Cheers
Rob
- Crashpilot1000
- Posts: 631
- Joined: Tue Apr 03, 2012 7:38 pm
Re: GPS integration
Ok, so no answer is an answer as well - no standard all fucked up in mwii - like always - even a month later. Maybe mwii or you needs years for that. I got another thing to think about, knowing that mwii doesn't care about the ground course reported by GPS I just want to report it anyways: your scaling is wrong.
Cheers Kraut Rob
Cheers Kraut Rob
I2c conection on CN-06 V1
Hi to all,
Just asking:
After i read a lot of pages i dont see any post from someboby to try to integrate I2c from CN-06.
Is hard to comunicate directly ?
Regards,
Just asking:
After i read a lot of pages i dont see any post from someboby to try to integrate I2c from CN-06.
Is hard to comunicate directly ?
Regards,
- mOuchadino
- Posts: 15
- Joined: Sat Jul 07, 2012 3:51 am
Re: GPS integration
multiwii 2.2 I2C Gps nav beta version
the video as bellow
the video as bellow
Re: GPS integration
Not thru I2C Nav Board.
Not FC-> I2C Nav Board -> CN-06 GPS .
Cn-06 has I2C comunication pins.
So i wish : FC->CN-06 GPS (thru I2C).
Until now i find a code and i'm able to receive data thru I2c from GPS, sentences GPC and RMC.
I will post later results.
Itrying to figure out how to decode data how is in serial GPS.
I'm beginner in programming.
I will try to use new I2C library wich is smaller and faster.
This is the code :
Not FC-> I2C Nav Board -> CN-06 GPS .
Cn-06 has I2C comunication pins.
So i wish : FC->CN-06 GPS (thru I2C).
Until now i find a code and i'm able to receive data thru I2c from GPS, sentences GPC and RMC.
I will post later results.
Itrying to figure out how to decode data how is in serial GPS.
I'm beginner in programming.
I will try to use new I2C library wich is smaller and faster.
This is the code :
Code: Select all
// How to get data from u-blox Evaluation kit EVK-7N through I2C interface
// example for Arduino Uno
#include <recoonI2C.h>
#define BUFFER_SIZE 190
uint8_t gpsAddress = 66;// adica in hex 0x42
uint8_t buf[BUFFER_SIZE];
void setup() {
Serial.begin(115200);
twi_init(100000); // or 100000 Hz (standard mode)
}
void loop() {
delay(200);
uint16_t bytes = twiReadBytes(gpsAddress, 0xFD, (uint8_t *) buf, 2);
uint16_t totalBytes = ((uint16_t) buf[0] << 8) | buf[1];
Serial.print("GPS is ready to transfer ");
Serial.print(totalBytes, DEC);
Serial.println(" bytes");
while (totalBytes) {
uint16_t bytes2Read;
if (totalBytes > BUFFER_SIZE) {
bytes2Read = BUFFER_SIZE;
} else {
bytes2Read = totalBytes;
}
bytes = twiReadBytes(0x42, 0xff, (uint8_t *) buf, bytes2Read);
for (uint8_t i = 0; i < bytes; i++) {
Serial.print(char(buf[i]));
}
totalBytes -= bytes2Read;
}
Serial.print("Serial println gol");
Serial.println();
}
Re: GPS integration
Hello Guys,
Can i connect the Ublox Neo6M I2C output pins directly to the Multiwii SE board I2C input (thus not using the GPS-I2C-NAV board)?
Can i connect the Ublox Neo6M I2C output pins directly to the Multiwii SE board I2C input (thus not using the GPS-I2C-NAV board)?
Re: GPS integration
Yes.
Note: you didn't specify whether you wanted it to work or not.
Note: you didn't specify whether you wanted it to work or not.
Re: GPS integration
timecop wrote:Yes.
Note: you didn't specify whether you wanted it to work or not.
LOL, you cracked me up!
i would like it to work.
Re: GPS integration
I'm having a bit of trouble - probably something I'm doing wrong, but a bit of guidance would be appreciated!
I have a MultiWii 328P Flight Controller w/FTDI & DSM2 (from HobbyKing) together with a Flytron Navigatron v2 GPS board (recently purchased) connected via I2C.
This all works well with MultiWii v2.2 software, but after updating to v2.3 I'm getting a load of I2C errors and the board is locked up. Basically, the board runs OK if GPS is commented out in v2.2 and v2.3, and is OK if GPS is enabled in v2.2 - it just won't work in v2.3
Do I have to update the Navigatron board to match v2.3, or have I missed a trick somewhere along the line?
Thanks...
UPDATE: I may have found the answer for myself - it looks like I2C GPS is broken in v 2.3
LINK: http://www.multiwii.com/forum/viewtopic.php?f=8&t=4246&start=10#p43256
I have a MultiWii 328P Flight Controller w/FTDI & DSM2 (from HobbyKing) together with a Flytron Navigatron v2 GPS board (recently purchased) connected via I2C.
This all works well with MultiWii v2.2 software, but after updating to v2.3 I'm getting a load of I2C errors and the board is locked up. Basically, the board runs OK if GPS is commented out in v2.2 and v2.3, and is OK if GPS is enabled in v2.2 - it just won't work in v2.3
Do I have to update the Navigatron board to match v2.3, or have I missed a trick somewhere along the line?
Thanks...
UPDATE: I may have found the answer for myself - it looks like I2C GPS is broken in v 2.3
LINK: http://www.multiwii.com/forum/viewtopic.php?f=8&t=4246&start=10#p43256
Re: GPS integration
Hi everyone, I have searched through the forum and did not manage to find any answers to my problem.
This is my problem:
I am using the following:
Arduino Due
MediaTek-3329 V2.0 from BYOD: http://www.buildyourowndrone.co.uk/Medi ... 9-v2.0.htm
The code that I got was from the APM project:
My initial setup was like this:
Due ---- MediaTek
5V 5V
GND GND
Tx0 Tx
Rx0 Rx
I read somewhere that SoftwareSerial.h is removed from Arduino Due.
I then removed all the code and left with
This output was seen on the serial monitor.
From this I know the communication works. However no matter what I add, I am unable to obtain a continuous flow of data.
I tried this but to no avail:
The serial monitor would show "0" continuously.
Connecting the Tx and Rx of the GPS to Tx1 and Rx1 of Due and changing the loop section
still shows "0". In other words there aren't values coming into the Rx1 of Due.
Any help is much appreciated
This is my problem:
I am using the following:
Arduino Due
MediaTek-3329 V2.0 from BYOD: http://www.buildyourowndrone.co.uk/Medi ... 9-v2.0.htm
The code that I got was from the APM project:
My initial setup was like this:
Due ---- MediaTek
5V 5V
GND GND
Tx0 Tx
Rx0 Rx
Code: Select all
GPS.ino:1: fatal error: SoftwareSerial.h: No such file or directory
compilation terminated.
I read somewhere that SoftwareSerial.h is removed from Arduino Due.
I then removed all the code and left with
Code: Select all
void setup() {
Serial.begin(38400);
}
void loop() {
}
This output was seen on the serial monitor.
Code: Select all
$GPGGA,125714.200,5458.8807,N,00136.9402,W,1,5,1.99,115.0,M,47.8,M,,*42
$GPGSA,A,3,10,13,04,23,02,,,,,,,,2.22,1.99,0.99*05
$GPRMC,125714.200,A,5458.8807,N,00136.9402,W,0.00,176.97,240114,,,A*76
$GPVTG,176.97,T,,M,0.00,N,0.00,K,A*33
From this I know the communication works. However no matter what I add, I am unable to obtain a continuous flow of data.
I tried this but to no avail:
Code: Select all
...void loop() {
int flag;
flag = Serial.available();
Serial.print(flag);
Serial.print("\n");
delay(100);
}
The serial monitor would show "0" continuously.
Connecting the Tx and Rx of the GPS to Tx1 and Rx1 of Due and changing the loop section
Code: Select all
flag = Serial1.available();
Serial.print(flag);
Serial.print("\n");
still shows "0". In other words there aren't values coming into the Rx1 of Due.
Any help is much appreciated
Re: GPS integration
You need to cross RX & TX I think.
Best regards
kopinke
Best regards
kopinke
Re: GPS integration
Hello,
I am using the FMP04 connected via Serial2 to my Flyduino.
I am now a bit uncertain, what Firmware to flash. In config.h it says:
On the other hand, I read that for 10Hz (which I think is recommended), 38400 Baud is not sufficient. Which again is confusing, as I have two firmwares:
Can you enlighten me?
Regards,
Hendrik
I am using the FMP04 connected via Serial2 to my Flyduino.
I am now a bit uncertain, what Firmware to flash. In config.h it says:
Code: Select all
// avoid using 115200 baud because with 16MHz arduino the 115200 baudrate have more than 2% speed error (57600 have 0.8% error)
#define GPS_BAUD 38400
On the other hand, I read that for 10Hz (which I think is recommended), 38400 Baud is not sufficient. Which again is confusing, as I have two firmwares:
Code: Select all
FMP04_Camled_010320_A1.5E_20110118_10Hz_38400
FMP04_Camled_010327_A1.5E_20110118_10Hz_115200
Can you enlighten me?
Regards,
Hendrik
Re: GPS integration
henfri wrote:Hello,
I am using the FMP04 connected via Serial2 to my Flyduino.
I am now a bit uncertain, what Firmware to flash. In config.h it says:Code: Select all
// avoid using 115200 baud because with 16MHz arduino the 115200 baudrate have more than 2% speed error (57600 have 0.8% error)
#define GPS_BAUD 38400
On the other hand, I read that for 10Hz (which I think is recommended), 38400 Baud is not sufficient. Which again is confusing, as I have two firmwares:Code: Select all
FMP04_Camled_010320_A1.5E_20110118_10Hz_38400
FMP04_Camled_010327_A1.5E_20110118_10Hz_115200
Can you enlighten me?
Regards,
Hendrik
It should work with 115200... but would buy a cheap ublox instead....
- KritzelKratzel
- Posts: 1
- Joined: Wed Oct 08, 2014 4:13 pm
- Location: Germany
- Contact:
Question on V2.1 firmware
Hi,
I’m using a Navigatron V2 GPS module (http://www.flytron.com/sensors/180-i2c-gps-for-multiwii-and-others.html) which implements the standard I2C_GPS_NAV V2.1 firmware compiled for MTK protocol. I’m using this module because of its I2C-capabilities and the ability to power it with just 3.3V. The module is attached to my 3D-FPV camera (http://www.rcgroups.com/forums/showthread.php?t=2238942), the GPS information read from the module shall be embedded into a 3D-stereoscopic OSD, which is included in the camera firmware. I don’t have an extra (conventional) OSD-module in use, because it’s not compatible with stereoscopic (side-by-side) video.
The cam is controlled by an FPGA, the FPGA is programmed in VHDL and all I2C-master logic is implemented on the FPGA. While studying the I2C_GPS_NAV V2.1 firmware with focus on how to read the Distance-To-Home (DTH) I have noticed something, from which I’m unsure whether it’s made with intention or whether it’s a bug. In file I2C_GPS_NAV.ino:315 the function GPS_distance_cm is defined as uint32_t:
In line 1317 this function is used to compute the DTH (in cm). The result of this computation is immediately saved into the I2C register map via:
So far so good. However, a quick look on the definition of the structure I2C_REGISTERS reveals, that there are only 16 bits reserved for the DTH (line 106):
Does this mean, that the assignment to i2c_dataset.distance_to_home in line 1317 at the time of execution saves 32 bits while over-writing the subsequent struct-component ground_speed?
In summary – if my observation is right (I’m not a C/C++ expert) and considering little-endian style of the MEGA328P – I could live with the situation of having just the lower 16 bits of the DTH available, if there wasn’t the limitation in maximum distance: max value in i2c_dataset.distance_to_home = 0xFFFF cm = 65535 cm = 655m.
Did anybody fly beyond that boundary while observing an DTH overrun in the OSD? Or is simply the “right” DTH value computed somewhere else on the flight control board, ignoring the presence of the I2C register with the (incomplete) DTH computation?
Any comments welcome.
Thanks,
Michael
I’m using a Navigatron V2 GPS module (http://www.flytron.com/sensors/180-i2c-gps-for-multiwii-and-others.html) which implements the standard I2C_GPS_NAV V2.1 firmware compiled for MTK protocol. I’m using this module because of its I2C-capabilities and the ability to power it with just 3.3V. The module is attached to my 3D-FPV camera (http://www.rcgroups.com/forums/showthread.php?t=2238942), the GPS information read from the module shall be embedded into a 3D-stereoscopic OSD, which is included in the camera firmware. I don’t have an extra (conventional) OSD-module in use, because it’s not compatible with stereoscopic (side-by-side) video.
The cam is controlled by an FPGA, the FPGA is programmed in VHDL and all I2C-master logic is implemented on the FPGA. While studying the I2C_GPS_NAV V2.1 firmware with focus on how to read the Distance-To-Home (DTH) I have noticed something, from which I’m unsure whether it’s made with intention or whether it’s a bug. In file I2C_GPS_NAV.ino:315 the function GPS_distance_cm is defined as uint32_t:
Code: Select all
uint32_t GPS_distance_cm(int32_t lat1, int32_t lon1, int32_t lat2, int32_t lon2)
In line 1317 this function is used to compute the DTH (in cm). The result of this computation is immediately saved into the I2C register map via:
Code: Select all
i2c_dataset.distance_to_home = GPS_distance_cm(…
So far so good. However, a quick look on the definition of the structure I2C_REGISTERS reveals, that there are only 16 bits reserved for the DTH (line 106):
Code: Select all
uint16_t distance_to_home; // distance to home in cm
Does this mean, that the assignment to i2c_dataset.distance_to_home in line 1317 at the time of execution saves 32 bits while over-writing the subsequent struct-component ground_speed?
In summary – if my observation is right (I’m not a C/C++ expert) and considering little-endian style of the MEGA328P – I could live with the situation of having just the lower 16 bits of the DTH available, if there wasn’t the limitation in maximum distance: max value in i2c_dataset.distance_to_home = 0xFFFF cm = 65535 cm = 655m.
Did anybody fly beyond that boundary while observing an DTH overrun in the OSD? Or is simply the “right” DTH value computed somewhere else on the flight control board, ignoring the presence of the I2C register with the (incomplete) DTH computation?
Any comments welcome.
Thanks,
Michael
Re: Question on V2.1 firmware
KritzelKratzel wrote:Hi,
I’m using a Navigatron V2 GPS module (http://www.flytron.com/sensors/180-i2c-gps-for-multiwii-and-others.html) which implements the standard I2C_GPS_NAV V2.1 firmware compiled for MTK protocol. I’m using this module because of its I2C-capabilities and the ability to power it with just 3.3V. The module is attached to my 3D-FPV camera (http://www.rcgroups.com/forums/showthread.php?t=2238942), the GPS information read from the module shall be embedded into a 3D-stereoscopic OSD, which is included in the camera firmware. I don’t have an extra (conventional) OSD-module in use, because it’s not compatible with stereoscopic (side-by-side) video.
The cam is controlled by an FPGA, the FPGA is programmed in VHDL and all I2C-master logic is implemented on the FPGA. While studying the I2C_GPS_NAV V2.1 firmware with focus on how to read the Distance-To-Home (DTH) I have noticed something, from which I’m unsure whether it’s made with intention or whether it’s a bug. In file I2C_GPS_NAV.ino:315 the function GPS_distance_cm is defined as uint32_t:Code: Select all
uint32_t GPS_distance_cm(int32_t lat1, int32_t lon1, int32_t lat2, int32_t lon2)
In line 1317 this function is used to compute the DTH (in cm). The result of this computation is immediately saved into the I2C register map via:Code: Select all
i2c_dataset.distance_to_home = GPS_distance_cm(…
So far so good. However, a quick look on the definition of the structure I2C_REGISTERS reveals, that there are only 16 bits reserved for the DTH (line 106):Code: Select all
uint16_t distance_to_home; // distance to home in cm
Does this mean, that the assignment to i2c_dataset.distance_to_home in line 1317 at the time of execution saves 32 bits while over-writing the subsequent struct-component ground_speed?
In summary – if my observation is right (I’m not a C/C++ expert) and considering little-endian style of the MEGA328P – I could live with the situation of having just the lower 16 bits of the DTH available, if there wasn’t the limitation in maximum distance: max value in i2c_dataset.distance_to_home = 0xFFFF cm = 65535 cm = 655m.
Did anybody fly beyond that boundary while observing an DTH overrun in the OSD? Or is simply the “right” DTH value computed somewhere else on the flight control board, ignoring the presence of the I2C register with the (incomplete) DTH computation?
Any comments welcome.
Thanks,
Michael
Good catch, it is really a bug (or a limitation). It limits the usable distance to 655meters, it does not overwrite ground_speed because it casts the in32 to int16.... Anyway i2c_gps_nav is discontinued now.
Re: Question on V2.1 firmware
EOSBandi wrote:.... Anyway i2c_gps_nav is discontinued now.
That is a real shame.
-
- Posts: 46
- Joined: Thu Aug 07, 2014 6:40 pm
Re: GPS integration
EOSBandi wrote:Anyway i2c_gps_nav is discontinued now.
Wha ohhh! That puts a major dent in my plans!!!
Just to confirm, does this mean there is no more support for i2C GPS in MW 2.3-2.4 at all? Are there better options for integrating GPS into 8Bit controllers?
I have a thread outlining my current project here- viewtopic.php?f=6&t=5536 where I explain that I'm trying to add GPS to a MW Flying Wing that uses an 8 Bit ATMega32u4 microcontroller. My project parameters specify that only generic (e.g Arduino, ATMega328/32u4 etc...) components be used in place of any specialized equipment (even those cheap i2c-gps adapters).
I was under the impression that my only option would be to roll my own adapter by flashing an additional Pro Mini with the i2c-gps-nav library to function as the i2c slave device. I was going to use an MTK3339 GPS module.
Can anybody clarify what my options are for an 8Bit microcontroller?
Re: GPS integration
Hi,
on my holybro 328p I have installed 1717 revision with #define I2C_GPS enabled.
With this configuration MWConfig can't connect to fc.
If I put comment at //#define I2C_GPS the connection with MWConfig start work perfectly.
Any idea ?
thx
on my holybro 328p I have installed 1717 revision with #define I2C_GPS enabled.
With this configuration MWConfig can't connect to fc.
If I put comment at //#define I2C_GPS the connection with MWConfig start work perfectly.
Any idea ?
thx
-
- Posts: 97
- Joined: Mon Sep 08, 2014 12:25 am
Re: GPS integration
mine was working well until a few days ago and has now decided to not work.. can't really understand why.. it was getting a lock in about a minute or even less sometimes.. using custom serial to i2c board made with a pro mini arduino now it just sits there flashing slowly the blue led..
gutted... it dones work anymore, and it was working so well...
gutted... it dones work anymore, and it was working so well...