| Versions |
  |
|
| Author |
 Topic  |
|
gr8
5 Posts |
 Posted - 01 nov. 2009 : 00:54:31
|
BT747 is not work with old Nokia 6600. If i understood corretly BT747 needs CLDC 1.1 and this phone has only CLDC 1.0. If i try to install BT747 i got error message "Wrong Version".
I like to use this logger in my RC-plane with 5hz logging, now i have to keep laptop with me for setting 5hz in flying field.
|
 |
|
|
mdeweerd
798 Posts |
Posted - 01 nov. 2009 : 02:23:00
|
The Nokia 6600 is listed amongst the supported phones on getjar (http://www.getjar.com/mobile/17413/bt747---bt_j2me-midlet-suite/?s=phones). It looks like they are wrong.
However, you can try to open the jar file like a zip and edit MANIFEST.MF in the META-INF directory of the jar. Change CLDC-1.1 to CDLC-1.0. [if you also use the jad ifle, you need make a change there too].
I believe that CDLC-1.1 is needed for floating point calculations. Possibly, that is not a problem for you purposes.
|
|
|
|
gr8
5 Posts |
Posted - 08 nov. 2009 : 20:55:50
|
| [quote snipped] I modified the file like you suggested and finally succeeded with installation, but bt747 won't start. Nothing happen when i try to run it. |
|
|
|
wilfred
Netherlands
9 Posts |
Posted - 27 nov. 2009 : 21:48:15
|
Hi José
Referring to your post some years ago of the bluetooth tweak of your Qstarz 810: I have bought an iblue747 A+ and it's a quite good device, but after 1 day trying to control it via bluetooth, I think I have a similar problem as you did at the time.
I tried to use the BT747 program from soundforge, but was not able to communicate with my device, whereas it's no problem via the USB cable.
Now the PCB in the 747A+ is quite different, I'm an electronics engineer, but I hardly see any resemblance :(.
So I was wondering: could you give me a hint how you would tackle this situation? (maybe you have found some documentation which helped you in locating the spot where the 1k was needed)
Greetings
Wilfred
|
|
|
|
mdeweerd
798 Posts |
Posted - 27 nov. 2009 : 21:54:01
|
Hi Wilfred
The iBlue 747 A+ should not have a hardware limitation for the bidirectional communication - the one I have doesn't.
Id did not check this on the A+, but what I observed in the earlier devices is that when the GP* sentences are turned off, the bluetooth communication is nil.
Do you get the current GPS position over bluetooth or not? That is step 1 to confirm connection and incoming reception.
Step 2 would be getting some of the other information related to the logger such as memory used which confirms bidirectional communication.
Step 3 is adjusting the download settings. This can be tricky and actually depends on the host - I think it has very much to do with the reception buffer size. |
|
|
|
wilfred
Netherlands
9 Posts |
Posted - 27 nov. 2009 : 22:12:10
|
Hi Mario!
I was just subscribing to your internet site www.bt747.org, to ask you the question too, and now you already reply to this post. Incredible :)
Happy to hear that I don't have to solder in the device too ;)
Well the thing is that I'm using my PPC to do the tests. I installed your software+superwaba and it runs on the PPC. But as soon as I connect to the GPS, the pocketpc freezes and has to be rebooted. The BT-port 6 that I use is receiving GPS data (checked with other programs, like tomtom, GPSinformation, VisualGPSce).
Because the other applications that I used don't give more info than NMEA data, I don't know how to perform your Step2/3. Could you help out on this ?
PS: Your BT747 program on the PC runs fine with the 747A+ by USB cable. I can download data, convert it (GREAT!), clear the memory. However, the thing I would like to achieve is to be able to do the same from the PPC (for travel reasons).
Do you prefer to have the discussion here, or on your www.bt747.org website?
continued : Maybe good to add: I'm using a PPC:
-Fujitsu-Siemens LOOX720
-Windows Mobile 2003 SE
-Intel PXA272 520MHz processor
-126MB memory.
UPDATE:
Somehow I got it running!
I have tried half an hour to make it again malfunctioning, but somehow it started working, and I can't make it crash anymore. It is very very strange. The only thing I can think of is: it may have started working since the moment I have taken the device apart, which involved taking out the battery ?!
Anyhow: the BT747 software runs now fine on the PPC.
The download of 19% memory took 15minutes.. Erasing took <1min.
Greetings & thanks for your help
Wilfred |
Edited by - wilfred on 28 nov. 2009 00:39:12 |
|
|
|
mdeweerd
798 Posts |
Posted - 28 nov. 2009 : 10:42:42
|
I am subscribed to this thread. Both here or bt747.org are fine by me - it is just that this thread is getting quite long ... As I do not really look at new threadss on gpspassion, the only way to make sure I see the post is in this thread or in any content on bt747.org.
It could be that taking out the battery made a change - I would not know what it changed. One would need to have a pictures of the device configuration before and after that event to try to get a hint.
I would say that step 2 is now achieved.
Step 3 involves tweaking the chunk size and read ahead (= pipeline of requests). The timeout can be left intact.
What follows will be a bit too technical for most, but since our degrees are in the same field, I suppose that you can follow.
The bigger the chunk size is, the less overhead there is in the communication (NMEA response type, checksum, ...) and the faster the device chains responses (less time between NMEA sentences). However, that also means that if the FIFO on the receiving end is "small", that that buffer gets filled resulting in the loss of data. Loss of data means that a recovery mechanism requests the same data again. With a big pipeline, the recovery takes longer.
Making the chunks smaller means more overhead, but also more time lost between responses. That is where the read ahead requests come in. This builds up a pipeline of requests. The device will be sending a chunk of data but will already have received requests for N more. Having received the requests already, the throughput is improved.
Another factor is bluetooth. Compared to USB more communication problems occur. That automatically results in a random need for recovery sequences. Therefore, the chunk size should not be too big over bluetooth.
So ideally one requests big chunks in the absence of communication issues - this is the default setting in the desktop version. In the mobile device versions the chunk size is smaller by default. It can be often increased, but I tried to choose a 'safe' setting working on most devices regardless of the speed.
|
|
|
|
wilfred
Netherlands
9 Posts |
Posted - 28 nov. 2009 : 21:57:06
|
Hello Mario
Very useful info. And indeed completely understood :)
I will try to optimize soon. Maybe tomorrow. Today I did some
windsurfing with the device, so I have a nice log to experiment with ;)
Memory is 9% filled. 391924 (9236 records)
When I was downloading the data over BT today, the transfer stopped at ~ 387000b,
when I restarted the download, it stopped at 420276b.
when I restarted again (+reboot PPC, which may not have been needed but i was locking up the device at an experiment), it finished the download at ~2096920b, which equals roughly 2MByte. Calculated back, this 2MB took 41 minutes.
But regardless of the speed (which I will try to optimize later), I found it strange that the device downloaded 2MByte?
note: I can see that the 391924 (given by the program) / 2^22 *100%=9%.
Also 9236records/99061total=9% (all given by the program)
Wilfred |
|
|
|
mdeweerd
798 Posts |
Posted - 28 nov. 2009 : 22:36:44
|
If the device was in 'overwrite' mode on erase, then then entire content will be downloaded.
In overwrite mode, when filled, the device will overwrite from the start of the memory. It will also report that the memory is 9% filled while it is actually 9% overwritten. To make sure that all data is downloaded, the full memory is fetched. 'Normal download' will only fetch the 9% (rounded on 64kB boundaries) but will start from 0. Smart download catches up where it stopped or where logging stopped.
|
|
|
|
wilfred
Netherlands
9 Posts |
Posted - 29 nov. 2009 : 16:57:29
|
Well. Experiments have led to the following:
the larger the chunk and the larger the # of requests, the better the datarate.
I could not find an optimum, just: the bigger the better.
But above certain chunk size, it does not help anymore.
The datarate that I achieved with 5requests, 100000 chunksize is
4.0kBps (32.1kbps)
The 4MB is downloaded in 17minutes.
My previous datalogger seemed to do this faster, so I checked objectively.
download speed of my previous datalogger+related PPC application:
Emtac Trine II gps-datalogger(sirf II), same PPC, Crux application
2.9kBps (23.2kbps), independent of baudrate setting.
So this means you have beaten the Emtac Trine PPC application. Congratulations!
So I thought that the TrineII was faster but apparently the TrineII stores much less data per gps point (actually: ~158bits versus ~3633 for the A+), so it could be downloaded faster.
My next question would be (if you are still interested), what would be the settings of the A+ to minimize the amount of data written per record, while still maintaining accurate location information, including height (I guess that should be sufficient to calculate actual speed etc. afterwards). What would be the drawback of such an optimization?
I was also experimenting with the switch you mentioned in the last post: "overwrite on full memory", but had some issues there. I was using the Desktop.
Sometimes the download took 3minutes, but most of the time 1.10minutes, I had the 3 minute thing a few times, but I don't know yet how to initiate consistently this strange behaviour, I tried already a lot. What didn't help, is that the Desktop software does not have a button to cancel the downloading of records, like the PPC version has (which was very handy during the download speed optimization).
Another, more interesting thing I observed. Maybe your software can be made more rugged. I have namely a clue why the download of records sometimes stops during the transfer of data.
Generally spoken, it appears that after 2.5minutes, the A+ in NAV modus terminates the BT connection with the PPC, if it is not connected to an application that *uses* the BT connection. (BT connection between PPC and A+ will dissapear from BT manager).
Strangely enough, it sometimes happens within the BT747 PPC application during datalog download, but never when I use the A+ in combination with e.g. Tomtom.
I think it is related to the chunksize+request setting. Originally it was set to 220 size+3requests. Maybe that is just on the edge of the threshold detector in the A+ that decides whether the BT is used or not. So, sometimes, when downloading the records to the PPC, the decision would be taken that the bluetooth traffic is so low that the A+ decides to switch it's bluetooth module to 'sniff' mode, thereby breaking the bluetooth connection with the PPC. Would it not be possible to turn off this low-power feature in the A+, when BT747 is downloading information, just like you turn off the datalogging of the A+ during such a transfer?
I must say, I'm really happy with your nice program! |
|
|
|
mdeweerd
798 Posts |
Posted - 29 nov. 2009 : 18:58:04
|
In theory the iBlue 747 (A+) does not officially support data download over bluetooth.
While I guess that there is a way to turn off the low power feature, I do not know how.
Based on your finding it seems recommended to reconnect after a while.
Given that the TOMTOM application is entirely passive - it is very strange that the device would conclude that there is no activity when there actually is a lot.
I should add log download cancellation - for the moment you can cancel by disconnecting.
Optimising the data downloaded is possible in all applications and you get some feedback about how many positions you'll be able to log in the logger based on the setting.
There is no influence on precision - logging is just observing what the GPS is reporting.
I recommend to log as a minimum: UTC, LAT, LON and PDOP. I use PDOP to determine the precision of the position (there is a filter in BT747). All other fields are up to your likings. RCR is needed if you want to know why the position was logged (button, special waypoint, speed, distance, ...).
Thanks for your feedback ;-). |
|
|
|
wilfred
Netherlands
9 Posts |
Posted - 29 nov. 2009 : 20:13:26
|
You're of course most welcome. I hope it helps. Thanks for the support!
Ok for minimizing the record size. I'll use your recommandations.
I agree that it is strange that the A+ would conclude low activity when it's read by BT747. But so far no better idea. I scanned the ether, but no other BT activity over here that could interfere. It's just the PPC and the A+, running on their own battery... I hope it won't bother me anymore since the change to larger chunksize.
Another strange one. Some posts ago you write:
" 'Normal download' will only fetch the 9% (rounded on 64kB boundaries) but will start from 0 "
But whatever I try it keeps on downloading the full 4MByte. both PC and PPC. Do I do something wrong, or is it maybe an unintended change that slipped into the program code?
BTW: the A+ doesn't like the abort download by disconnect.
Oh no. UPDATE: what happened? I changed some settings in BT747, I don't remember exactly which ones (logging options etc) , but now the 'Normal download' is suddenly fast as you said. Both PC and PPC. I'm flebberguested! I tried it sooo many times, how can it change all of a sudden. My guess: be happy and don't touch it anymore :)
Now = time to relax in a different way :) |
Edited by - wilfred on 29 nov. 2009 20:30:12 |
|
|
|
mdeweerd
798 Posts |
Posted - 29 nov. 2009 : 20:51:58
|
'Normal Download' - I forgot: the standard application downloads everything when in overwrite mode, so I think I made BT747 do the same (but I would need to check that). Anyway: I try to keep it as safe as possible (no loss of data).
The first block is not in overwrite mode only if you set the device to 'Stop on full' followed by an erase operation. Surely something like that happened.
You are pretty lucky with your PPC since the bluetooth supports the big chunks. The 'smart download' will download the data 'incrementally' so when traveling you can fetch the log 'daily' to get yourself a backup copy and to limit the download time per session.
|
|
|
|
wilfred
Netherlands
9 Posts |
Posted - 29 nov. 2009 : 23:10:21
|
Yes I did that (stop on full, then erase), so the crazy stuff made sense after all.
(I thought I was going crazy). Man, you know what you're talking about.
I made you a micro donation. But you're worth every penny :-) |
|
|
|
mdeweerd
798 Posts |
Posted - 29 nov. 2009 : 23:48:30
|
| Thank you for the microdonation - it is always a pleasure to see a token of recognition. |
|
|
|
Topic |
|
|
|
| This page was generated in 1,98 seconds. |
 |
|
- 
- 
* Discussing MTK receivers and Tips and Tweaks *
