Do i need a GPS Reciver ? I tought that it will calculate the location over Triangulation ?
On Tue, Jan 25, 2011 at 10:34 AM, Holger Hans Peter Freyther < holger@freyther.de> wrote:
On 01/25/2011 08:33 AM, MArc Richter wrote:
But when i convert it into a kml file with gsmmap i can't see any GPS koordinates. Why ?
Do you have a GPS receiver attached to your computer?
On 01/25/2011 10:40 AM, MArc Richter wrote:
Do i need a GPS Reciver ? I tought that it will calculate the location over Triangulation ?
You will need one, even for triangulation you will need to some base coordinates. Please feel encouraged to create a wiki page for the cell_log application to describe its requirements and features.
Relevant sourcecode to initiate opening the GPS device: http://bb.osmocom.org/trac/browser/src/host/layer23/src/misc/cell_log.c#L789
On 01/25/2011 10:44 AM, Holger Hans Peter Freyther wrote:
Relevant sourcecode to initiate opening the GPS device: http://bb.osmocom.org/trac/browser/src/host/layer23/src/misc/cell_log.c#L789
I can't make it work. The first issue was the /dev/ttyACM0 in the source code (my gps is /dev/ttyUSBX). I modified it in the code, but I think that a cmd line option would be nicer. I don't see any debug/error log lines, but no coordinates appear in my log file. Any hint? My gps receiver works fine with other softwares.
On Tue, Jan 25, 2011 at 12:01 PM, Dario Lombardo dario.lombardo@libero.itwrote:
Any hint?
contribute!
let the GPS warm up, maybe it just needs to start tracking the sats, or add a printf to dump what data is coming from the GPS
2011/1/25 Dario Lombardo dario.lombardo@libero.it
On 01/25/2011 10:44 AM, Holger Hans Peter Freyther wrote:
Relevant sourcecode to initiate opening the GPS device:
http://bb.osmocom.org/trac/browser/src/host/layer23/src/misc/cell_log.c#L789
I can't make it work. The first issue was the /dev/ttyACM0 in the source
code (my gps is /dev/ttyUSBX). I modified it in the code, but I think that a cmd line option would be nicer. I don't see any debug/error log lines, but no coordinates appear in my log file. Any hint? My gps receiver works fine with other softwares.
So anyone is changing the code to use the config from the osmcom.cfg file for the gps feature ? Or is this a missunderstanding on my side?
On Tue, Jan 25, 2011 at 12:34 PM, n0p [Luis Bernal] lbernal@gmail.com wrote:
let the GPS warm up, maybe it just needs to start tracking the sats, or add a printf to dump what data is coming from the GPS
2011/1/25 Dario Lombardo dario.lombardo@libero.it
On 01/25/2011 10:44 AM, Holger Hans Peter Freyther wrote:
Relevant sourcecode to initiate opening the GPS device:
http://bb.osmocom.org/trac/browser/src/host/layer23/src/misc/cell_log.c#L789
I can't make it work. The first issue was the /dev/ttyACM0 in the source code (my gps is /dev/ttyUSBX). I modified it in the code, but I think that a cmd line option would be nicer. I don't see any debug/error log lines, but no coordinates appear in my log file. Any hint? My gps receiver works fine with other softwares.
On 01/25/2011 01:51 PM, MArc Richter wrote:
So anyone is changing the code to use the config from the osmcom.cfg file for the gps feature ? Or is this a missunderstanding on my side?
patches welcome, no harm if two people work on this. Personally I would prefer command line parameters as cell log is not using a config file yet.
On 01/25/2011 01:57 PM, Holger Hans Peter Freyther wrote:
patches welcome, no harm if two people work on this. Personally I would prefer command line parameters as cell log is not using a config file yet.
Me too. But cell_log uses the "common/main.c", so if we put it in that file, that would be shared between all "layer23" apps. Is it ok or anyone can suggest another way?
On 01/25/2011 02:17 PM, Dario Lombardo wrote:
Me too. But cell_log uses the "common/main.c", so if we put it in that file, that would be shared between all "layer23" apps. Is it ok or anyone can suggest another way?
For command line options. Each app can have its own set, just add them to the one already present for the cell_log (e.g. to disable rach bursts). If you go for config file parsing, make sure that no config file is required (keep it optional). But then again parameters are preferred by me.
z.
Nice so if anyone could add this feature. I would write a Wiki page how to use this
On Tue, Jan 25, 2011 at 2:21 PM, Holger Hans Peter Freyther holger@freyther.de wrote:
On 01/25/2011 02:17 PM, Dario Lombardo wrote:
Me too. But cell_log uses the "common/main.c", so if we put it in that file, that would be shared between all "layer23" apps. Is it ok or anyone can suggest another way?
For command line options. Each app can have its own set, just add them to the one already present for the cell_log (e.g. to disable rach bursts). If you go for config file parsing, make sure that no config file is required (keep it optional). But then again parameters are preferred by me.
z.
On 01/25/2011 04:30 PM, Dario Lombardo wrote:
awesome!
- case 'g':
snprintf(gps.device, 32, "%s", optarg);LOGP(DGPS, LOGL_INFO, "Using GPS device %s\n", gps.device);
two issues there.
1.) you can use ARRAY_SIZE(gps.device) in case we ever shrink/increase this. In reality this should be PATH_MAX/MAX_PATH or such.
2.) snprintf will not add a '\0' of optarg is of the length of 32 or longer
On 01/25/2011 04:34 PM, Holger Hans Peter Freyther wrote:
On 01/25/2011 04:30 PM, Dario Lombardo wrote:
awesome!
- case 'g':
snprintf(gps.device, 32, "%s", optarg);LOGP(DGPS, LOGL_INFO, "Using GPS device %s\n", gps.device);two issues there.
1.) you can use ARRAY_SIZE(gps.device) in case we ever shrink/increase this. In reality this should be PATH_MAX/MAX_PATH or such.
2.) snprintf will not add a '\0' of optarg is of the length of 32 or longer
Very good. This is the new patch that should fix both.
On 01/25/2011 04:46 PM, Dario Lombardo wrote:
On 01/25/2011 04:34 PM, Holger Hans Peter Freyther wrote:
On 01/25/2011 04:30 PM, Dario Lombardo wrote:
awesome!
Very good. This is the new patch that should fix both.
Almost perfect. I can apply and modify myself or you could do two things. We tend to avoid the '//' comments, they were only added in C99 and used to be a GCC extension for C. The other is you could (if you want to) use git commit and then git format-patch. This way I don't need to copy and paste your name and mail address.
tell me what you prefer holger
Something's going wrong when I try to commit.
git commit . git formal-patch git push
Last one returns "fatal: The remote end hung up unexpectedly". Am I making something wrong?
On 01/26/2011 01:43 PM, Dario Lombardo wrote:
Something's going wrong when I try to commit.
git commit . git formal-patch git push
Last one returns "fatal: The remote end hung up unexpectedly". Am I making something wrong?
git format-patch will create a patch for you. You can send this to the mailinglist. git push is only for people thay can send commits to the server.
Dario Lombardo wrote:
Very good. This is the new patch that should fix both.
..
- printf(" -g --gps DEVICE /dev/ttyACM0. GPS device.\n");
- printf(" -b --baud BAUDRATE The baud rate of the GPS device\n");
What is the default baud rate? And where in the code are these defaults being set?
@@ -118,6 +123,16 @@ static int l23_cfg_handle(int c, const char *optarg) case 'n': RACH_MAX = 0; break;
- case 'g':
snprintf(gps.device, ARRAY_SIZE(gps.device), "%s", optarg);// force string terminatorgps.device[ARRAY_SIZE(gps.device - 1)] = '\0';
-1 should be outside the parentheses.
//Peter
On 01/25/2011 08:24 PM, Peter Stuge wrote:
Dario Lombardo wrote:
- printf(" -g --gps DEVICE /dev/ttyACM0. GPS device.\n");
- printf(" -b --baud BAUDRATE The baud rate of the GPS device\n");
What is the default baud rate? And where in the code are these defaults being set?
src/common/gps.c, statically initialized.
On 01/25/2011 16:34, Holger Hans Peter Freyther wrote:
2.) snprintf will not add a '\0' of optarg is of the length of 32 or longer
Actually it does, even though it may truncate the resulting string in the process:
« snprintf() and vsnprintf() will write at most size-1 of the characters printed into the output string (the size'th character then gets the terminating `\0') »
HTH,
On 01/26/2011 05:55 PM, Pierre Pronchery wrote:
On 01/25/2011 16:34, Holger Hans Peter Freyther wrote:
2.) snprintf will not add a '\0' of optarg is of the length of 32 or longer
Actually it does, even though it may truncate the resulting string in the process:
« snprintf() and vsnprintf() will write at most size-1 of the characters printed into the output string (the size'th character then gets the terminating `\0') »
The trailing null byte won't be added to str, if the string is truncated.
from man snprintf on a Linux machine.
Hi,
On 01/26/2011 21:28, Holger Hans Peter Freyther wrote:
On 01/26/2011 05:55 PM, Pierre Pronchery wrote:
On 01/25/2011 16:34, Holger Hans Peter Freyther wrote:
2.) snprintf will not add a '\0' of optarg is of the length of 32 or longer
Actually it does, even though it may truncate the resulting string in the process:
« snprintf() and vsnprintf() will write at most size-1 of the characters printed into the output string (the size'th character then gets the terminating `\0') »
The trailing null byte won't be added to str, if the string is truncated.
from man snprintf on a Linux machine.
first, I have to admit that the manual on Linux is very confusing and unclear about snprintf(), which is why I pasted an extract from BSD.
Still, if you do: === BEGIN PASTE === $ cat snprintf.c && make snprintf && ./snprintf #include <sys/utsname.h> #include <stdio.h> #include <string.h>
int main(void) { struct utsname uts; char buf[16]; int res;
if(uname(&uts) == 0) printf("%s %s\n", uts.sysname, uts.release); memset(buf, 0xff, sizeof(buf)); res = snprintf(buf, 4, "%s", "AAAAAAAA"); printf("snprintf() returned %d, buf[3] = 0x%02x\n", res, buf[3]); return 0; } cc snprintf.c -o snprintf Linux 2.6.9-023stab052.4-enterprise snprintf() returned 8, buf[3] = 0x00 === END PASTE ===
Which would tend to argue in my direction, as this was run on a Debian Lenny host.
However, as I was kindly reminded by a friend in the meantime, you are also right. Even though POSIX/SUSv3 itself says:
http://pubs.opengroup.org/onlinepubs/009695399/functions/printf.html
« The sprintf() function shall place output followed by the null byte, '\0', in consecutive bytes starting at *s; it is the user's responsibility to ensure that enough space is available.
The snprintf() function shall be equivalent to sprintf(), with the addition of the n argument which states the size of the buffer referred to by s. If n is zero, nothing shall be written and s may be a null pointer. Otherwise, output bytes beyond the n-1st shall be discarded instead of being written to the array, and a null byte is written at the end of the bytes actually written into the array. »
(the last sentence is important here)
there are platforms indeed which do not respect this: http://msdn.microsoft.com/en-us/library/2ts7cx93%28v=vs.80%29.aspx
So on Windows you are right.
Now I guess the question is: is OsmocomBB intended to support non-POSIX platforms natively?
HTH,
On 01/27/2011 01:04 PM, Pierre Pronchery wrote:
Now I guess the question is: is OsmocomBB intended to support non-POSIX platforms natively?
Hi Pierre,
thanks for digging into this. My general attitude is to assume the worst. It is one of the functions that can have portability issues, it is somehow good to know that the situation is looking better than i though.
Nice ! But do you want to deploy this patch to the repository to gave everyone this feature ?
On Tue, Jan 25, 2011 at 4:30 PM, Dario Lombardo dario.lombardo@libero.it wrote:
On 01/25/2011 02:43 PM, MArc Richter wrote:
Nice so if anyone could add this feature. I would write a Wiki page how to use this
Attached there is my patch to support cmd line gps in cell_log.
On 01/25/2011 12:34 PM, n0p [Luis Bernal] wrote:
let the GPS warm up, maybe it just needs to start tracking the sats, or add a printf to dump what data is coming from the GPS
I still can't make the gps working. In gps.c the line from serial port is parsed to find $GPGLL. My device doesn't give this line. These are the lines that it gives me
$GPGGA $GPGSA $GPGSV $GPRMC
$GPGGA should give the position as $GPGLL should, but the software doesn't use it. Is it correct to say that the positioning data could be taken from different NMEA data? If yes, is it reasonable to add the support for other messages?
I still can't make the gps working. In gps.c the line from serial port is parsed to find $GPGLL. My device doesn't give this line. These are the lines that it gives me
$GPGGA $GPGSA $GPGSV $GPRMC
$GPGGA should give the position as $GPGLL should, but the software doesn't use it. Is it correct to say that the positioning data could be taken from different NMEA data? If yes, is it reasonable to add the support for other messages?
i've had the same issue. Use the attached patch to read the required data from the $GPGGA NMEA sentence.
- Martin
On 01/28/2011 07:08 PM, Martin Hauke wrote:
i've had the same issue. Use the attached patch to read the required data from the $GPGGA NMEA sentence.
- Martin
Good, but why did you change the old code? Why don't you put something like
if (strcmp("$GPGLL") { // run the old code } else if(strcmp("$GPGGA)) { // run your new code } else { return; }
That could support both the devices.
if (!strcmp("$GPGLL") { // run the old code } else if(!strcmp("$GPGGA)) { // run your new code } else { return; }
would work better... ;-)
On Mon, Jan 31, 2011 at 1:34 PM, Dario Lombardo dario.lombardo@libero.it wrote:
On 01/28/2011 07:08 PM, Martin Hauke wrote:
i've had the same issue. Use the attached patch to read the required data from the $GPGGA NMEA sentence.
- Martin
Good, but why did you change the old code? Why don't you put something like
if (strcmp("$GPGLL") { // run the old code } else if(strcmp("$GPGGA)) { // run your new code } else { return; }
That could support both the devices.
On Mon, 31 Jan 2011 13:34:16 +0100, Dario Lombardo wrote:
Good, but why did you change the old code? Why don't you put something like
if (strcmp("$GPGLL") { // run the old code } else if(strcmp("$GPGGA)) { // run your new code } else { return; }
That could support both the devices.
BTW, best practice would be to implement parsing of the "GPRMC"-sentence as it is the "Recommended Minimal Sentence" for every NMEA-capable gps receiver. It contains time, date, latitude, longitude, validity, speed and heading, so everything needed is delivered and should work with all receivers out there.
Regards, Mad
I don't see a huge problem here.
Why not just parse whatever message with interesting info we get?
if (!strcmp("$GPGLL") { // extract coordinates and update buffer } else if(!strcmp("$GPGGA)) { // extract coordinates and update buffer } else if(!strcmp("$GPRMC)) { // extract coordinates and update buffer } else if(!strcmp("$GPSuperProprietaryMessageWithAwesomePrecisionData")) { // extract coordinates and update buffer } else { // no luck with this message return; }
Sebastien
On Mon, Jan 31, 2011 at 4:28 PM, mad@auth.se wrote:
On Mon, 31 Jan 2011 13:34:16 +0100, Dario Lombardo wrote:
Good, but why did you change the old code? Why don't you put something like
if (strcmp("$GPGLL") { // run the old code } else if(strcmp("$GPGGA)) { // run your new code } else { return; }
That could support both the devices.
BTW, best practice would be to implement parsing of the "GPRMC"-sentence as it is the "Recommended Minimal Sentence" for every NMEA-capable gps receiver. It contains time, date, latitude, longitude, validity, speed and heading, so everything needed is delivered and should work with all receivers out there.
Regards, Mad
On 01/31/2011 05:08 PM, Sébastien Lorquet wrote:
I don't see a huge problem here.
Why not just parse whatever message with interesting info we get?
if (!strcmp("$GPGLL") { // extract coordinates and update buffer } else if(!strcmp("$GPGGA)) { // extract coordinates and update buffer } else if(!strcmp("$GPRMC)) { // extract coordinates and update buffer } else if(!strcmp("$GPSuperProprietaryMessageWithAwesomePrecisionData")) { // extract coordinates and update buffer } else { // no luck with this message return; }
I agree with this approach. I think that is scales well if a new device (even not nmea) wants to be supported.
On 01.02.2011 09:43, Dario Lombardo wrote:
On 01/31/2011 05:08 PM, Sébastien Lorquet wrote:
I don't see a huge problem here.
Why not just parse whatever message with interesting info we get?
if (!strcmp("$GPGLL") { // extract coordinates and update buffer } else if(!strcmp("$GPGGA)) { // extract coordinates and update buffer } else if(!strcmp("$GPRMC)) { // extract coordinates and update buffer } else if(!strcmp("$GPSuperProprietaryMessageWithAwesomePrecisionData")) { // extract coordinates and update buffer } else { // no luck with this message return; }
I agree with this approach. I think that is scales well if a new device (even not nmea) wants to be supported.
how about a proper gpsd-integration? I've some spare time in the end of this month to try it. I would parse only one least common NMEA-sentence. As Mad said the "GPRMC"-sentence should be a good candidate for this. All other GPS-input-messages could be read via libgpsd from gpsd (which seems to be able to read even most obscure GPS-binary formats).
best regards, Martin
Hi,
if (!strcmp("$GPGLL") {
...
how about a proper gpsd-integration? I've some spare time in the end of this month to try it. I would parse only one least common NMEA-sentence. As Mad said the "GPRMC"-sentence should be a good candidate for this. All other GPS-input-messages could be read via libgpsd from gpsd (which seems to be able to read even most obscure GPS-binary formats).
if anyone wants to continue on that, I had started with something similar already in the past, but not continued:
http://vogel.cx/git/0001-GPS-Support-for-GPRMC-sentence.patch
You can already use gpsd by creating a fifo, and telling it to osmocom as a device. Then, in another session, run gpspipe -r >fifo.
Greetings,
Chris
It would also be nice to have a dummy-GPS mode, where you could put the longtitude/latitude as a command line argument for gsmmap.
I think most people won't move much debugging with osmocon, so a static position is sufficient.
But: there is already an application for GPSd, gpsfake which can fake positions (and can give a static position). If full GPSd-compatibility is made, this would be redundant.
On 02/01/2011 08:13 PM, Martin Hauke wrote:
how about a proper gpsd-integration? I've some spare time in the end of
I took a look at the gpsd integration libs and these are my considerations:
PROS: - lib seems easy to use and easy to integrate to existing osmocom code - using gpsd avoids to parse lines directly and makes osmocom work with any (gpsd-supported) device
CONS: - the use of it makes the presence of gpsd necessary and creates a dependancy from libgpsd when compiling - if we use libgpsd, this is not backward-compatible with existing serial parsing code
Finally, my opinion is that using gpsd is better then reading from the port, so if the mantainers of the code agree with me I think I could write the code.
Let me know. Dario.
I would leave the possibility of using the current GPS code by using a define at compile time, so when compiling for an embeeded platform (like android, armstrong or equivalent) you do not rely on having the gpsd library and daemon available
2011/2/7 Dario Lombardo dario.lombardo@libero.it
On 02/01/2011 08:13 PM, Martin Hauke wrote:
how about a proper gpsd-integration? I've some spare time in the end of
I took a look at the gpsd integration libs and these are my considerations:
PROS:
- lib seems easy to use and easy to integrate to existing osmocom code
- using gpsd avoids to parse lines directly and makes osmocom work with any
(gpsd-supported) device
CONS:
- the use of it makes the presence of gpsd necessary and creates a
dependancy from libgpsd when compiling
- if we use libgpsd, this is not backward-compatible with existing serial
parsing code
Finally, my opinion is that using gpsd is better then reading from the port, so if the mantainers of the code agree with me I think I could write the code.
Let me know. Dario.
CONS:
- the use of it makes the presence of gpsd necessary and creates a
dependancy from libgpsd when compiling
- if we use libgpsd, this is not backward-compatible with existing serial
parsing code
Make _sure_ it's not required. The configure should test for it and disable its usage (and fall back to either the old code, or no GPS support at all).
Cheers,
Sylvain
On 01/25/2011 12:40 PM, Peter Stuge wrote:
Dario Lombardo wrote:
The first issue was the /dev/ttyACM0 in the source code (my gps is /dev/ttyUSBX). I modified it in the code, but I think that a cmd /line option would be nicer.
Please fix the code so that it uses the value from the config.
It is not using the config at all. At the congress I added the possibility that apps can have app specific config options. So it should be relative trivial to add two options for the baudrate and the device. This should be about 15 lines of code. I don't have a GPS device, it works for Andreas like it is, so someone should step and contribute this 15 lines of code.
So let me short summarize this 1. conntect GPS device 2. in the config (osmocom.cfg) change the following lines from ..... ! gps device /dev/ttyACM0 gps baudrate default no gps enable ! ms 1 sim reader ....... to .... ! gps device /dev/ttyACM0 gps baudrate default gps enable ! ms 1 sim reader .....
3. run Cell_log 4. convert Cell_log with gsmmap to a valid .kml file
is this correct ?
On Tue, Jan 25, 2011 at 10:44 AM, Holger Hans Peter Freyther < holger@freyther.de> wrote:
On 01/25/2011 10:40 AM, MArc Richter wrote:
Do i need a GPS Reciver ? I tought that it will calculate the location over Triangulation ?
You will need one, even for triangulation you will need to some base coordinates. Please feel encouraged to create a wiki page for the cell_log application to describe its requirements and features.
Relevant sourcecode to initiate opening the GPS device:
http://bb.osmocom.org/trac/browser/src/host/layer23/src/misc/cell_log.c#L789
baseband-devel@lists.osmocom.org
-
Christian Vogel -
Dario Lombardo -
Hermann Maier -
Holger Hans Peter Freyther -
mad＠auth.se -
MArc Richter -
Martin Hauke -
n0p [Luis Bernal] -
Peter Stuge -
Pierre Pronchery -
Sylvain Munaut -
Sébastien Lorquet