2 minute boot delay if radio missing

[Jesse-EE]

I put firmware for a 5605 (With a radio) onto my 5601 (without a radio) and it causes a 2 minute delay on powerup before it starts responding to either the CU or the Ranger/TSCe.

Is there a way I can disable it from expecting to find a radio? Evidently it waits for 2 minutes trying to get a response from the radio before proceeding.

Unfortunately, this sometimes causes the CU to power off before the 5600 is ready to play!

WORK AROUNDS:

1: Use a data collector which you can connect any time, including after the 2 minute timeout.
2: Power up CU via it's own power port, and when it goes into offline mode, unplug power. Next time it is powered up, it may pause and say "Powered off by illegal function, press OK" and the prompt may wait there for long enough that the 2 minutes is up and the 5600 is ready to play.
3: Install a radio out of any other 5600 or 600 series. You don't have to use the radio, it just needs to be able to say "hi" to it.

As a side note, the radio bay inside the 5600/600 series is huge. I think a 2 or 3 hour battery could be placed inside there, possibly with a modern legal bluetooth wireless bridge radio.

As another side note, the OEM radio (H25, 0.1W, 450Mhz) probably communicates via RS232 because there's a MAX232C chip on there. It should not be too hard to put a scope on there and figure out which is data pins and find out what text exchange takes place, and make a small micro chip emulate that so the unit believes there's a radio there.

Even without the radio, it does seem to do all the other functions, including tracking an RMT.

[robots]

The firmware dump also contains configuration of "available" peripherals. Its possible to "disable" the radio by changing the Fw you upload to the station.

[Jesse-EE]

The firmware dump also contains configuration of "available" peripherals. Its possible to "disable" the radio by changing the Fw you upload to the station.

That makes sense!

Is there any information available on how I can turn on/off "available" peripherals?

Also, is there a field in the firmware I can change to make it think it's a 5601 that it really is?

Also, have you looked at all into the protocol for the built in radio? I see it's gota a MAX232 so it's likely RS232. With all that space in there it would be fun to load it with batteries and a microcontroller that pretends to be the OEM radio but uses some modern legal radio link. I keep telling myself I should poke around in there with scope/logic analyzer but haven't got around to it yet.

[robots]

From the firmware point of view all stations are the same, 560x, 550x, 600, all stations are the same. The name is given as field in the firmware, and the peripherals are enabled in one big array. The better precision is that the "calibration" data is more precise. I am not even sure that the HW is different. It all looks the same when i checked. So for me the HW versions are: 400, 4400, 500, 600+5600+5500 (these are all the same, just trimble 5xxx versions are yellow, and have new EDM - DR (direct reflection) or time of flight DR 200/300)

I dont have access to the firmware reverse project now. So i can not help you instantly.

The radio protocol is: AT commands. But i dont have them documented. + there are 2 extra pins. These pins are connected to the PWR board (power supply). One pin can keep the radio enabled even when station is OFF, and second pin can wake up the station remotely (yes, RPU can turn off and turn on station).

[robots]

Its their own AT commands. Dont expect full AT modem command set :-)

[Jesse-EE]

Its their own AT commands. Dont expect full AT modem command set :-)

Understood! I'm used to interfacing Microchip PIC mcu's to strange little wifi modules, Italian cellular modules, Iridium satellite modems, and the like -- and they all have their own strange set of ill documented AT commands :-D

[Jesse-EE]

All very interesting! And thank you so much for the responses and info!

I dont have access to the firmware reverse project now. So i can not help you instantly.

That sounds ominous....

The radio protocol is: AT commands. But i dont have them documented. + there are 2 extra pins. These pins are connected to the PWR board (power supply). One pin can keep the radio enabled even when station is OFF, and second pin can wake up the station remotely (yes, RPU can turn off and turn on station).

Excellent to know! Thank you!

It sounds like you have enough information collected that a person could actually write an open source OS for the series, and bring life into a lot of these old robotic stations.

I'm sure you're incredibly busy but if you ever wish to shoot me an email, here's my email address partremmaps@gmail.com I would certainly enjoy chatting with you about your experience with these old Geodimeters!

[robots]

Soo .... i dont know how much are you willing to dig into this.

The address is 0x1df3, and on station with tracker and radio you will see value of 0x3f here. Radio is the bit 0x10. so 0x2f will fix your problem :)

[Jesse-EE]

@robots Thank you!!! I definitely want to eliminate the need for the OEM radio if I can because that's a pretty nice space in there, I might put batteries or an aftermarket legal radio in that compartment!

[robots]

S1131DF0001F801F001F00010001614E000191AC13

I think you are looking for this line in the dump :)

[Jesse-EE]

S1131DF0001F801F001F00010001614E000191AC13

I think you are looking for this line in the dump :)

Thank you!
The closest matching line I have in "5605-DR200+_firmware-from-altenplos-via-email-04252024.hex" is:

grep S1131DF0001 5605-DR200+_firmware-from-altenplos-via-email-04252024.hex
S1131DF0001F001B001F000400170A0BFFF5A2D7E9

If I did this right, I have a 1B there, so I should try a 0x0B. (And update the checksum of course.

Out of curiosity, is there a list of features to bits mapped out in any of the repository? If so I sure would love to go explore that specific document!

[robots]

The repo is called firmware :) I have disassembly in front of me.

Those bits are angle board present, servo present, edm present, radio present, tracker present. (in no particular order)

There is another "feature word" which tells whether the station is "pro", "Ats" or constructor.

[Jesse-EE]

@robots I do apologize, I'm not experienced with github. Is the repo one of these? Nothing jumps out at me.

I'm assuming you have some document that identifies the meanings of the bits, as a simple disassembly isn't going to produce comments or variable/bit-field names from the original source code. You must have spent quite a lot of time figuring out just what each bit does, and I'm curious if you've published that information or if I'm on my own there :D

Thanks and have a wonderful day!

[robots]

No its not github. I have the firmware for station in disassembler. This is not made public yet. This is where i get the information.

[robots]

S1131DF0001F801F001F00010001614E000191AC13

I think you are looking for this line in the dump :)

Thank you! The closest matching line I have in "5605-DR200+_firmware-from-altenplos-via-email-04252024.hex" is:

grep S1131DF0001 5605-DR200+_firmware-from-altenplos-via-email-04252024.hex S1131DF0001F001B001F000400170A0BFFF5A2D7E9

If I did this right, I have a 1B there, so I should try a 0x0B. (And update the checksum of course.

Out of curiosity, is there a list of features to bits mapped out in any of the repository? If so I sure would love to go explore that specific document!

Yes, you need to recalculate the checksum of that line only. The firmware checksum is calculated once uploaded to station

[Jesse-EE]

No its not github. I have the firmware for station in disassembler. This is not made public yet. This is where i get the information.

Ok understood. Thank you! When you said "The repo is called firmware" I thought you might have a repo called firmware that I might look through, I figured if it was all published there's no need for me to bug you for details when I could go look myself :D

I do have a question - is there a vertical scale angle offset value hardcoded?

When I put Altenplos's 5605 firmware on my 5601, I am no longer able to perform the zenith angle offset or vertical index calibration or whatever it's called (the routine where you put it in a certain mode and do a face left and a face right and it learns and compensates for F1-F2 difference.)

When I do the procedure, it fails, saying the angle is too great or whatever. And indeed, F1 and F2 readings are more than a degree apart.

However, if I just do a normal F1/F2 reading of a target and average them, it's dead on.

I did try physically rotating the position encoder, but it hits against physical obstructions and I cannot rotate it far enough.

So I'm thinking there's a hardcoded angle offset for the vertical angle sensor, and if I could bump that up or down a degree or so then I could null out my F1/F2 difference.

Thanks!