malc-c

LOL - cross posting Just installed python, but again it's going to be a learning curve.... thanks for the file - saved me a lot of hair pulling

Archie, whilst I can code in PicBasic, and understand Arduino.... I'm getting out of my depth here with Python scripting.... I have no idea on which of the two files to download nor what to do with them once downloaded.... Any chance you can supply the HEX file as requested ? I just tried the python -- version command and it's not recognised, so guess I would need to install python ?

Archie, Can you download the firmware for the goto dob flexitube from SW, convert it to HEX and either upload or drop me a PM with it attached or a link to a file download (dropbox or similar) Cheers

I tried that C:\Users\Administrator\Desktop\Firmware>python bin2hex.py -b MC004.bin -o MC004.hex 'python' is not recognized as an internal or external command, operable program or batch file. C:\Users\Administrator\Desktop\Firmware> I have both .py files in the same folder as the firmware and bin2hex

Right... the "useful" help file on their website didn't say anything about using the scripts ! I could load your EQ6 hex just fine.

If I run the normal command line bin2hex file.bin file.hex the conversion happens, but when I try to load the HEX file into PicFlash (I use an EasyPIC development board for PICs) I get the error shown in the attached image

Archie, that's the same convertor I've downloaded. The only thing that I don't understand is line 2 using the py extension and I presume <cr> means hit enter ?

Can you provide a link to the convertor tool you used. The Bin2Hex convertor I just tried is command line, and whilst it produced an output it's not recognised by the PIC programmer. If this is the same utility can you remember what options / switches you used in the command line to produce a viable HEX file

Archie, Thanks for the input. I've been in conversation with Astro-Geek as I have the ability to program PICs, but had no way to srip the wrapper from the downloadable firmware file to leave just the HEX I'll have a play and see if I can burn a chip and post it to him Excellent post, thank you

Just a follow up... I've been able to do three or four imaging sessions since and now get into a workflow where having calibrated I now use the guide assistant when on target. Currently imaging M106 and after an hours worth of guiding this is the result. Stars are nice and round, and I'm happy with those RMS error results

As mentioned earlier in this thread, at the time I was working for then back in the early 1980's Tasco US (which is where we ordered our product range through) had some nice high end scopes. Whilst our orders were placed through Tasco in the US, the goods arrived direct from Japan / China. I can't say for sure (its been almost 40 years since I worked for Tasco), but it's quite possible that they were indeed re-badged Celestron's and Vixens under licence. I was sure there was a market for them, but the UK business model was aimed at high turnover for a modest profit, rather than tying up cash in high end stock items. Also given the lead time, it wasn't feasible for custom one off orders.

I do have a com port sniffer... but don't have any hand controllers to do the pass through. You can bet your bottom dollar that Synta probably use the PIC in the hand controller to remove the encapsulation when its set to PC Direct mode, so even if you used a sniffer between the PC and the hand controller it would all be garbage....

Just to keep anyone else following this thread up to speed, I've been in daily communications via PMs as we try and resolve the issue. Thinking it was the driver chip, I persuaded Astro-Geek to purchase a replacement and suggested an easy way to remove the old one and solder the replacement to the board. Regretfully this had no effect, and the remaining two chips (a hex schmitt trigger and an OP-Amp ) were also replaced. Sadly the fault remained, and tonight Astro-Geek confirmed that all the discrete components have been tested by comparing like for like with the known working board. So this just leaves the PIC micro as the possible cause. Now Synta will have copy protected the raw HEX code, but as the firmware can be uploaded via a PC application this suggests the PIC as a bootloader running. The firmware that you can download from SW website is encapsulated in a wrapper so it's impossible to extract the raw HEX code and attempt a reprogramming.... The Copy protection also means that its not possible to read the code on the good board and then squirt it back to the faulty one..... So that basically means we can't do much more and that a new board is required. At least through deduction and Astro-Geeks willingness to attempt some resoldering (which by the image he sent me he did very well) we learnt a lot about these boards. Its been fun, and it would have been nice if the efforts resulted in a fix in the same way I fixed my HEQ5 with just a couple of capacitors, we'll just have to chalk this one up as unsolvable I'm sure Astro-Geek will keep us posted once OVL or other SW suppliers are able to source replacement boards from China

A lot of that detail is educated guesswork, and presumptions that other components haven't failed (I feel this is turning into a new Sherlock Holmes mystery - a lot of deducing !!) I'm not an electronics expert, but also having a background as an IT technician tend to follow a logical path when problem solving, which more often than not works... but I'm not infallible

Reading up on the goto dobs, they use DC motors with dual encoders on both axis. This would explain the two 4 pin headers labeled IR sens and the three pin Motor header. It would also explain how the scope can be moved whilst tracking, something that is difficult to do with stepper motors because stepper motors get locked by the two phases. Given this, it should be possible to use a standard DVM between GND and pin 3 and then GND and pin 8 to see if there is any voltage being sent to the three way terminal header. If there is no voltage then this would confirm the L293DD chip has blown. Repeating this on the good board that is known working should confirm this. Again this is presuming that the DC motors are being controlled by pure DC and not some form of pulse width modulation, which would need some scope or logic analyzer to confirm, but from what i've researched this evening, the direction control (and speed) is via the corresponding GPIO pins going logic high or low...

I thought that, and I think I've discovered something. The motors in this mount may not be steppers. If you look at the large image on page one you see that pins 3 and 6 go to the two outer pins of the three pin socket labeled MOTOR. There are two capacitors between pins 3 and GND and 8 and GND. As there is only one set of two wires this would suggest the motor suggest that the motors used are DC, and that the use of precision encoders are used to maintain tracking. Not sure how the motors are locked off as steppers have a holding torque....

Ah, so it was more of a physical issue than electrical. I've used NEMA motors in s few projects and thought the flats an shaft lengths were standard. Mind you, wouldn't put it passed SW to come up with some " exclusivity" in order to sell them at infated prices

£3.99 from RS.. so not expensive

Assuming the processor is fine and sending pulses to the driver chip, then this would seem the possible cause.

Uhmm... the L293DD chip is a push pull four channel motor driver... so it could be that chip that's not working

My guess is that its a driver chips that's failed (possibly one or both of the 14 pin packages) on the master. I'm betting that the two boards are identical with the same firmware on each, and the two processors communicate using some CAN bus or similar, which is why the slave board works and you don't get any error messages on the handset. Can you advise what markings are on those chips. With some flux and careful use of a soldering iron those should lift quite easily and would be the things i would replace if this was my board

Right, I have a better understanding on how the mount is configured. Bit confuddled with each board having two motor terminals, one being three wires as most steppers use four so no idea what the 3 pin socket does. I know it seems obvious, but have you tried a different RJ45 lead (without a diagram its hard to know if it used a cross-over cable or straight through) Is power to the "slave" board fed through the same RJ45 lead ? They appear to be identical boards, other than one has the power switch and socket and the handset connector removed. I doubt that they would have different firmware on the processor (could be wrong).

The only problem there is that unless a component glows or smokes there is no means of telling if the current draw is excessive or not as SW don't release technical data at this level. - but good suggestion otherwise. That's surprising you had to wait so long as the steppers in the mount are standard NEMA brand and these are commonly available from loads of sources

I must admit I'm struggling here.... On the HEQ5 and EQ6 mounts there is a small interface board where the handset / power and ST4 cables can be plugged in, with a cable connection to a single motherboard. The two steppers connect to the motherboard directly. In your posts you give the impression that there are sub assembly boards with the motors on board rather than just the wires from the motors on each axis. But as you have plugged each axis motor / sub assembly into the board on the good known working port and they work, then it would suggest its the chip that that drives that axis that's the cause of the problem. Can you post up a connection diagram? I'm presuming that the other connectors on the board are for encoders so the mount can still track and goto even after a manual intervention? However, as mentioned, without test equipment to see what signals are like on the chips I doubt that you will ever get to the bottom of this issue. With OVL out of action and not able to give you a lead time on spares then its a case of sit and wait until restrictions are lifted and a replacement board can be sought.

I personally don't think this is something minor Observations: The handset communicates with the mount. You can move the mount in AZ. The PC software can communicate with the mount and identifies the existing firmware. - This means the processor is working on the main board. The mount can be moved via the hand controller in the AZ plane - this would suggest that power is getting through to the motors and that the driver chips on that axis is fine (assuming that when powered you have resistance in the motor of the axis that has failed). The fact that you get no movement on the ALT plane would suggest that either the motor is non-functional, or the driver chip or one of the associated support components has failed. The fact you swapped motor connections and it functioned would thus point towards component failure for the driver board used. Now unless you have access to scopes or other test equipment and SW were forthcoming with a schematic (the latter I doubt), and the ability to desolder and re-solder to component level then it might be time to bite the bullet and purchase a new board. The drawback is that OVL have closed (AFAIK) due to CV19. I'm only familiar with the HEQ5 which has the one main board rather than a mainboard and two driver board (you mentions swapping ALT and AZ boards). If this mount has two such "driver" boards and you#ve swapped them and the fault follows the board then it would indeed suggest in issue with just that board. This could be a simple capacitor or, and gut feeling, the actual chip that does the pulsing. The only fly in the ointment is the fact that whilst the PC software can read the existing firmware, the bootloader wasn't able to update it.