Modifying Columbus V900 chipset settings?

khaytsus's picture

I've just gotten a Columbus V900 a few days ago, and I'd like to tweak a few things like the logging distance and probably logging frequency as well, but so far I don't see any way to connect my Linux box via bluetooth to the device with BT747 and the PPC version of BT747 sort of seems to work but none of the values stay.

If I try it on a Windows machine at work, would it work on this model?  I know there are some limitations such as accessing the logs directly etc, but to modify the chipset settings?

Another question, right now I have some logs that I'd like to limit the data export to >= 10 feet (6m), but when I try it the export is always the same.  I think I'm doing it right..  On the first page/tab, I select the data, the Filter tab I turn on the Common Filter section and set 6 <= distance <= 0, then go back to the first page and click KMZ for export.  But it still exports all data.

mdeweerd's picture

The Colombus V900

  1. The Colombus V900 configuration is done through a file on the memory card (that is what I have in mind - I do not have such a logger).  Therefore, one needs to have access to the file system to change the configuration.
    I am not certain that access to the file system is available over bluetooth.
    It could be made possible I think to put the memory card in the PPC or the computer and modify the configuration on the logger card.

    I guess that BT747 can configure some of the values of the MTK chip (if the Columbus receives the commands over bluetooth), and I would think that the logger commands are not available anyway.  Configuration is surely limited at best to live NMEA sentence settings and some other things.
    'Only' a raw debug log of can help me shed some light on that.  What information does BT747 provide about the device?

    The bluetooth connection configuration itself has to be done in the system.  You should be able to set up a connection to the device using a serial profile (since you are able to do so on the PPC).

    Currently BT747 mainly supports the CSV logs, but not the V900 configuration file.  And, BT747 can configure the MTK chipset within the limitations set by the V900 firmware.
  2. I am not sure what you mean here.  My reply is the same: if your windows machine has bluetooth, you should be able to setup a serial connection.  As far as I know, the USB connection provides a virtual disk - you can not access the MTK chipset through that.
  3. That distance filter is using the distance field reported in the log.  The distance is not calculated in BT747.  That is something that I could add though (calculate the distance with the previous position if the distance is not provided in the log).  If you do have a distance field in the log, let me know, provide me with a sample log and I'll check it out.  In the sample V900 log files I have, the following header is available and it does not have the distance:
    INDEX,TAG,DATE,TIME,LATITUDE N/S,LONGITUDE E/W,HEIGHT,SPEED,HEADING,VOX
khaytsus's picture

When I get to work on Monday

When I get to work on Monday I'll try it on a Windows machine, none here at the house.  Perhaps it can communicate with the device and possibly change settings.

I've written a tool in Perl to parse the CSV data and output to a web service I run which does work fine, just seems silly to default to 1s logging intervals.  Although I guess one can filter from 1s, can't really interpolate from 5+ seconds with good accuracy sometimes.  :)  The defaults make for a really nice track log, but much more data tha needed.  My tool only draws a point if the angle changes more than # degrees or after a number of seconds, but only if the point is more than # feet away.  Greatly reduces the data for my web service without reducing the accuracy too much.

Anywho, cheers for the tool, it's excellent!  Hopefully I can use it on mine too, I'll report back.  :)

BTW, yes, you're right, there's a CONFIG.txt file you drop on the memory card to configure a *few* things, it's very minimal as far as I know, unless there are undocumented items..  Pro vs Std mode (*DOP's and perhaps a few other thngs are logged in Pro mode), Spy mode logging interval, over-speed warning, and I think that's it.. 

mdeweerd's picture

I haven't really concentrated

I haven't really concentrated on reducing the number of positions while maintaining a fairly good track.

My HTML output does doe a good job at something similar which is selecting the appropriate positions for a particular zoom level.

The kind of filtering you do in your tool could be added to BT747.

I tried to configure some

I tried to configure some settings too on my Columbus V900 - it does not remember anything but the logging interval though.

Since the distance between trackpoints can not be configured to be recorded into the V900's CSV files I can't use the distance filter - would appreciate if you could implement a function in BT747 that calculates the distance between track points to filter them.

Another filter I'd like to use would be one that filters out all but the track points at every n seconds.

cheers, Phil

as I understand it, chaging

as I understand it, chaging the 'configuration' of the V-900 is something of a misnomer... the device always records data ever second to the file it creates. The configuration change is really a configuration for the software, which will then reduce the amount of data it spits out after parsing the file.

 The only exceptions to the recording a loctation is that from what I've read, when you record 'voice' it stops recording GSP data during the time it's recording the wav file, it does not record any GPS data and also when its in Spy mode...

  At first when I read that the V-900 didn't actually have the ability to change how frequently that it actually records data, I thought that was not such a good thing, but the more I thought about it... I figure it's not really that bad. After all, you can store something like 12,500,000 points on a 1GB card, so you can still record about a half a year of log data on a 1GB card and it will support 2GB cards...   Bottom line that memory is cheap... and from what I've seen of the data file, it's not that hard to parse. So, the more I thought about it, it's no big deal, if fact maybe it's a good thing.

Maybe they should record every half second... :)

mdeweerd's picture

Hi It is something like that

Hi

It is something like that as I've understood it.

The data file is not particulary difficult to parse - but it could have been more 'standard'.

What Phil requested is not 'that hard' either, but has not been implemented at this time.