_Art_

Maybe they don’t like using the same names again, knowing that 001-008 names exist in another track. In reality, you wouldn’t really confuse the same names in an entirely different track. Have you tried that auto prefix feature of the 66 and seen what that does? Maybe changing a couple of letters as a prefix for each hike would reset the numeric part. None of this answers your question, it’s just some thoughts really. I haven’t even marked a waypoint on it myself, but have seen the prefix part in the menu IIRC.

It came out yesterday, and I got it first. It sux in every possible way. Garmin Topo LITE Australia is much better for half the price, and the HEMA raster mapping covers that up. The raster mapping is just Birdseye jnx files, which subtract from the total jnx files you can have on a device. The GPSr doesn’t know anything about what it’s displaying, where the Garmin Topo LITE vector map does. The raster mapping has limited street detail. The raster mapping includes contour lines which are fuzzy at some zoom levels. The POIs are more comprehensive, and include info about toilets, etc. for sites. POIs are free. I can’t even think of a single redeeming feature. These are both 64st screenshots compared HEMA to Garmin Topo V6. V6 is the full version, which is the same price. I should have turned Birdseye imagery off, but you can still see the contours. Garmin Topo screenshots are nigh time mode also. https://imgur.com/a/k0X2hyX Cheers.

I do have the envelope and pm area, but no new messages, and no messages at all. If it weren’t for the email I wouldn’t know I got a message. Yes I wasn’t going to mention that. It was about ten years ago, I expected it to work at the time, and they may well, but I never tested with a device. I did test and use 60CSx Whiz. With more experience, I wouldn’t send anything like that out into the world these days (Oregon/Colorado Whiz) without testing it on a device myself. 60CSx Whiz works great, but any online version could be infected with a 90’s trojan called “Virtob”. To use it, you’d have to have a virtual machine to burn. I lost source and exe for this, and helped spread a bad version no doubt, by downloading it, and further uploading it myself. With 64st Whiz I was a lot more careful. I still have no virus checker, but a clean computer just for the IDE, and was careful to make videos showing and describing it. I’ve got a stack of HDD caddies for this, with IDE installations that simply aren’t allowed on any network, except Microsoft for Windows Update, and Visual Studio.

@Atlas Cached I got email notification of a private message from you, and the email included the actual message, but nothing here? When I check one the forum, I’ve never received a pm yet since joining. Anyways, I’ve heard that before. Did Garmin say so? For 64st Whiz, I have the device for testing, but I don’t think I’ll ever have an Oregon. Although you can use photographic or cartoonish images, I wanted mainly to flatten the 64’s otherwise dithered textures, and just have plain flat colour backgrounds. I wasn’t even motivated to write it again for 66 because Garmin already did the GUI this way this time

I got the opportunity to chat with an authorised distributor from Hungary of all places, whom I met through an unrelated group. He checked one of his 66s for me, and also found 2.30 device firmware. It’s interesting that it’s installed on recent units, but WebUpdater still reports 2.10 as the current version if you try to update an early unit.

It’s still my favourite handheld of all time, taking into consideration the time it came out. I never recall it turning off any other way than flat batteries, or pressing the off button

From memory, the way to tell was the GPS module software version was prefixed with an “m”, and just reading a bit more now, it looks like device firmware 4.10 was shipped with these. http://forums.gpsreview.net/discussion/14007/60csx-no-longer-uses-sirf-chips

They are apparently up to version 2.40 now, and that has been shipped with new units since December 2018, but still no way to get it if you already have a unit that I know of.

I assume both the time stamp and GPSr serial number are used as part of the key. The timestamp for the current visit is displayed int he chirp information screen.

HI, I’ve done a little research, but was mainly bothered about hardware until about now. The low level RF communication I expect to be abstracted away by the OS, and the fellow who wrote that App linked above alluded to the same. It would be lucky for a proprietary thing like that to be out in the open. If it were full understood, my goal would probably be to replace the message, and make that dynamic, like the current temperature or something. So far what I can do is read in either SPI channel up to 8000 bytes (which is probably a number of complete transactions), and spit that out again slowly and Human readable, from a serial port to read on a terminal, or a file on SD card or something like that. The serial terminal is the easiest bet right now.

Hi A bit of an update. Never mind the terrible ringing on the scope traces... my scope probe there was just wires & alligator clips, but here’s an example SPI byte transmitted (I forget which direction this is relative to the mcu & RF transceiver). Scope SPI: https://imgur.com/a/QpYJKQP Too fast for software SPI functions, and I need one hardware SPI module for an SD card eventually, so I decided to make a third hardware SPI peripheral for the dsPic with two shift registers. This image shows the last byte in whatever packet was being transmitted on the row of eight white LEDs. Hardware SPI: https://imgur.com/a/u6dxQQu This allows my mcu SPI routine to read faster because the shift register hardware takes care of bit banging, and I only have to read in parallel bytes for that channel. The structure so far: Chirp Structure: https://imgur.com/a/JY0otbC Cheers.

THat’s one of them, but with any detailed map, if I zoom out far and just move the map around by browsing it will never last long before turning off.

For me yes. I’m sure I’ve already talked about it in this thread.

That’s interesting that it’s still not available yet. Has it crashed when browsing maps?

I suspect that the Ant support and the dongles do the encryption, and provide access to use it through an API. Being able to write an App doesn’t mean the author is privy to that kind of information, but it’s worth a shot. EDIT, I send an email and got a reply. It’s used through an API that wouldn’t provide access to encryption (that I’m assuming to be employed). Basically, for an example, anyone can write an iPhone App that plays music form the user’s library, but you can never see inside the music file, extract data from it, see frequency values to write a spectrum display, or anything else to access the music files. You basically get a list of songs, and tell the iPhone to play one of them. Not even Apple can access the actual data (I suspect) or their own music App would have a spectrum display.

Is there a way to reproduce this with a 64st on fw 5.10 if I’m in Australia? I’d guess that either the GPS or destination coords aren’t being sent to the distance function. The distance calculation itself is pretty benign stuff // calculate haversine distance in Km float getdistance(double lat1, double long1) { double lat2 = gpslat; double long2 = gpslon; double dlong = (long2 - long1) * d2r; double dlat = (lat2 - lat1) * d2r; double a = pow(sin(dlat/2.0), 2) + cos(lat1*d2r) * cos(lat2*d2r) * pow(sin(dlong/2.0), 2); double c = 2 * atan2(sqrt(a), sqrt(1-a)); float distf = 6367 * c; return(distf); }

I had trouble with support as well for my 64st. Basecamp couldn’t unlock or send the map product to the GPSr. It isn’t possible for me to call them, and also have a PC or even the GPSr at the same time at work, since the support line is business hours only. I ended up using piracy tools to unlock my own map, patch the device firmware, and basically go through all the motions of pirating a map that I paid for. For the 66st, I purchased the SD card version of the map.

I don’t expect much from it other than seeing valid data. I expect that to be encrypted though. Garmin wouldn’t want clones to be easily made. Since the GPSr sends the timestamp and serial number, I’d be using both of those to encrypt the rest of the transaction if it were me making it. It’s possible the timestamp and serial number will be in the clear, but they could also have some obfuscation known by the GPSr and Ant device. The serial was boring. While the Chirp is idle, it outputs “0xE0, 0x00” bytes every two seconds at 4800 baud 8N1. While transmitting to a GPSr, there’s a few more byte values in there, but none of it has any meaning in ASCII.

I’d say it’s the fastest the chips can do so that it can do it’s business quickly and go back to sleep. Maybe about a 10MHz SPI clock. I see activity on my scope, but it has issues with waveforms at that speed. I’ve also got LEDs on both data channels, and they make things more obvious. I totally forgot this thing has the transmit half of a serial port. It does output data, so I might as well go for the easy part first.

The 64st only takes a few seconds from turning chirp search on, to find the chirp, then another 6 or so seconds to read in it’s info. Most modern microcontrollers have low power sleep modes that are set to wake on desired events such as interrupts, or expiry of a timer. In this case both chips have. The transceiver probably wakes up when it’s selected with it’s enable pin. If only my scope had SPI decoding, I’d see the packets now, but unfortunately it will take me some more building and programming to get another microcontroller to do it.

So far that there’s a quick burst of activity on the bus every 2 seconds whether a device is searching for it or not.

As far as I’m aware, nobody has looked at it, so anything I find out is new. Here’s the still working chirp with exposed SPI interface. This also has a temporary PCB to test what is done so far. It lowers the voltage of one of the SPI data channels, and then mixes them both together with diodes so both data channels can be seen on one channel of a scope. One channel will be of lower amplitude than the other, so easily distinguishable which channel is which (which direction data is flowing), but both SPI data channels only using a single scope channel. https://imgur.com/a/xpZFHbr When I’m done with that, my own microcontroller (dsPic) daughterboard will go there.

Still works! https://imgur.com/a/rAxqpU1 All good from here I think. The third wire has a PCB via I can scrape the coating off, and use. The fourth wire is for the last pin on the side of the chip, so I can lead the wire in sideways. I’ll probably need a blob of potting compound to drop over it when done... before something breaks.

Ok, I’ve mounted it, and externally powered it without breaking it so far https://imgur.com/a/eC7Au6t The only hairy part is coming up. Breaking out the SPI interface between the microcontroller and transceiver chip to read it. Wish me luck! I got two of them in case of ruining one, but I’d rather keep the second chirp intact. I swear they called the whole thing Ant because of the two antenna pins. https://imgur.com/a/VGlWpEN .... and... four connections can’t be made across one side of the chip because the insulation won’t fit! I’ll have to stagger connections between both chips on the SPI bus. I didn’t foresee that one! https://imgur.com/a/oUvrj21

I’ve loaded more than 32GB of Birdseye imagery from Basecamp to the 66, and even when the imagery is already downloaded, it still takes a very long time to copy to the device. I never had any issue like that. I always plug the device in before turning it on. Not saying that makes any difference, but it is what I’ve done.