malc-c

No worries... in your own time

To be honest this one may be difficult to resolve because having googled the Skywatcher version it seems to use an connection hub to interface between the mount, camera and StarSense handset. I have no doubt that at the minimum there will be crossover wiring to ensure that the camera and handset is routed to the right pins on the mount. My hunch would be that there is actually some circuitry in there to do the routing and possibly a level shifter to convert the 5v TTL signals to 3.3v. Have both the AZ and ALT boards been fried or are you in the same boat Astrogeek was with just one board that was fried ? I've been googling for the past couple of hours to try and obtain some pinouts for the various ports, and to try and work out what voltages got shoved where without much success. Can you run through some of the things in that other thread to see if the PC updater application can communicate with either of the boards. Can you also confirm that the startsense version is the correct SW version.... if it is and its news then you may have some redress from the retailer as the device has caused the damage... The compatibility is a bit vague as it says "AZ Synscan mounts" but doesn't mentions Dobsonian goto mounts directly as it does HEQ5 / EQ6 / EQ8 etc. You say you can solder, does that include replacing SOIC chips? - If the consensus is that the PIC(s) have been blown then as they are the same as those used in AstroGeeks MC004 boards it would be an easy task to program a PIC or two and post them to you. But first we need to confirm that this is the issue.

Following on from your post in AstroGeek's thread where we resolved his issue after incorrectly connecting an EQDir cable to his ALT board on his goto Dob let's get some info and then we're start trying to work out a plan of action. Is the scope under warranty ? - If so then contact the dealer for assistance. The fact the starsense is for use with Celestron and not Skywatcher telescopes I very much doubt that any repair would be free of charge If the scope is out of warranty, which version of control board do you have. On AstroGeeks thread his scope used two MC004 boards, one for each axis. Newer models apparently have a single pcb populated with components, and a connector board for the AZ motor and sensors Did you hear anything go pop when you plugged the star sense unit into the mount We would need to research the pinouts for the startsense and whatever port you plugged it into so we can see what might have been blown. Do you have access to any test equipment, the basic would be a digital voltmeter Are you able to solder? If you have read all 7 pages of AstroGeeks thread then you can appreciate diagnosing issues with the mount can be a round-about process, but with help from other members it is possible to bring back boards from the dead, and even re[program the PIC microcontrollers on them.... so it's possible that we can resolve this for you. Anyway, let's start by gathering as much information as we can. However I didn't envisage starting a part time business repairing motor boards..... so can't promise that if it goes the same way as AstroGeeks board and the PICs were replaced that it would be as quick or as cheap... there is only so much Kama I can give

Ira, it might be worth starting a new thread for this... if you can include more information as to what you plugged in where, to what board, if both boards were connected at the time, and what actually happens when you connect the handset it will help. Are you able to check the board for any obvious damage?

LOL - to be honest, whilst I understand the basics, a lot of what Archie took me through with the conversion of the files and using python scripts from the command line was over my head too

Thanks, and having received a message from Astrogeek I can confirm that the board is now working 100% after reflowing a solder joint on a pin of the decoder chip, so now the mount moves smoothly in all directions and at all speed settings. I have to agree, seeing the number of posts here and on the EQMod group reporting blown boards, or the typical no response to directions you would have thought that even the basics of reverse polarity circuits or even a quick blow fuse, either self resetting or even a single use should be included to protect the rest of the electronics. On looking back at this, if we had replaced the PIC at the start, the cost would be no more than a couple of pounds, and in my case where my HEQ5 board was blown, 56p for two capacitors fixed the board, so it does peeve me when the manufacture, importer and retailers don't support repairs on boards that cost an average £120. If anything, this thread shows that such repairs are possible with the combined efforts of forum members. Without Archies expertise in processing the firmware file we would have struggled, at least until I had got answers from other forums or spent ages and ages googling for an answer. I'm sure if Archie wasn't 1000's of miles away on the other side of the globe he would have offered to have reprogrammed the PIC the same as I did.... The logistics being that both the OP and I are in the UK which made things a tad easier. Above all its been teamwork! In full transparency, even though I had said I required no payment for my part in this, the OP was very insistent, and having worked out the total costs came to £4.50 for the PIC and two lots of postage, the OP generously rounded that up to £10 for which I'm very grateful. I shall enjoy the couple of pints of stout that will get me at my local watering hole

Sounds like a plan, and I'm sure the beers will be on AstroGeek 🍻

It was a team effort. I couldn't have undertaken the swapping out of the PIC without Archies help in sorting the code, and you also put in a lot of effort in replacing the driver and encoder chips as well. I have no idea why it has that glitch below speed value of 5, but the fact it aligns, goto's and tracks is the main thing..... It's been challenging but fun, and I'm glad to have been involved in helping you out. It's what these forums are for. To share knowledge, experience and help where we can.

Well, I received a PM this afternoon.... AstroGeek had received the board and this time it worked. He can now move the mount in both AZ and ALT axis. However there are some quirky things happening that his testing has thrown up, and are beyond my understanding of how these boards and handsets function, so I'll let him list his findings later. By the sounds of it though, the mount tracks which is a result.....

I did the same in 2011, only used jubilee banding strap as 200mm jubilee clips were hard to find back then. As I now image rather than use the scope for visual observing I've since removed the rings

Archie, have you taken this down? I get a 404 error even after logging in

You know, electronics can be a baffling hobby. As mentioned above, I followed Archies advice and extracted a version of the motor board firmware that when programmed to a DIP version of the 16F886 responded with the firmware vision when interrogated by the PC application. I burnt the same code to an SOIC version of the same PIC and labelled it, ready for use on the board when it arrived. In the meantime Archie provided a proven copy of the firmware that responded to control codes, so I opted to use that. I then could not for the life of me reproduce the success I had a few days earlier and get any PIC with any version of the code to communicate through the USB Serial boards. I even soldered the SOIC chip that was programmed with the same code as the DIP chip that did respond to the PC application directly to the PC used to program it. I added a 20mhz crystal, 2x 22pf caps and a few wires and hooked up the 5v power. Again, when connected via the USB serial board the PC software reported it couldn't connect to the motor control board. I squirted Archies code to the PIC and had the same issue...... Each time I've tried reversing the two wires to the TX/RX pins on the USB serial board, and tried all baud rates in case this was the issue.... In order to see if there was an issue with the USB board I connected it to an Arduino and uploaded a simple bit of code that sent back the word "hi" each time any character is sent to it. Opening up a serial monitor connected to the correct port and sending A, or B resulted in "hi" pinged back.... so that works, but for the life of me have no idea why I couldn't get a response back from the PIC when connected.... I installed an old version of MPLAB IDE so I could confirm the configuration bits in Archies code, thinking that maybe the oscillator setting somehow gets changed, as the board has a 20mhz crystal, HS is normally set... and sure enough Archies code when read in to the IDE with the option to use the code settings has HS set... but still no joy.... Now it could be that the PIC is simply not running.... and as Skywatcher don't include a flashing LED on the board to confirm the PIC has a heartbeat, and there are no regular timing buses used (such as I2C) using a logic analyzer won't show a thing. Most pins are kept low, and without being able to send an instruction to the PIC can't test the pins that enable and output to the motor driver chips. So lets pray that the PIC is more happy connecting to the handset when AstroGeek receives the board back. Failing that all I could ask is for Archie to accept the challenge and take a look at the board..... but that may have a few logistical issues as I don't think he's in the UK. Or AstroGeek could look at the option of getting an original AZ board and make the modifications to convert it to an ALT board.... both of which would be a lot cheaper and quicker than the full replacement to the newer "upgrade". But hopefully we'll see a post on Monday with a video of AstroGeek dancing around his Dob as it rotates the OTA about its ALT axis

Well I seem to have resolved the issue with the FTDI boards.... one of the four breakout boards has a prolific chipset... windows complained about its driver, the driver installed, but still wouldn't work. After that ALL USB to serial boards stopped working, couldn't even get an echo back by connecting RX and TX pins together.... Having just uninstalled the driver my FTDI board now works I've parcelled up the motor controller board and will be posting it tomorrow... hopefully this time, with a 100% working code programmed into the PIC we should get a result..... unless the board has some other failed discrete parts that we simply can't find by testing in situ.

I'm beginning to realise why I moved over to Arduino and away from pics.... For the life of me I can't replicate my success of getting the PC application to talk to the PIC and retrieve the firmware version. Even when programming a DIP chip on the EasyPic5 board. I've tried three different USB boards, one that definitely used 5v TTL serial, and still nothing. I've downloaded the same terminal application as shown above and don't get anything back when sending the same command instructions. The pic gets programmed via the PicFlash application, so its not a power issue... so I'm sorta scuppered on how to test this further.... Getting back to the MC004 board, I'm 100% confident the PIC is programmed with Archies proven HEX code. I've taken some large scale images to help anyone trace out the board, but obviously some via's and tracks will be under components. If I can get this comms issue sorted I'll do some checking, but for now I've come to a grinding halt

Archie, thanks for the input and for working out how the boards are addressed. I'm not having much luck here. Having uploaded my copy of the HEX file to the PIC via ICSP (read back and verified by PICKit2) I hooked up two test wires form pins 5 and 7 of the 8 way socket on the board (as this would be the serial connection between both boards). No matter what port settings or which way round I had the wires I couldn't retrieve the firmware version via the PC application using the FTDI board. (this may be due to the reasons you describe above). I can confirm the FTDI is working as linking the tx/rx together results in an echo back when an ascii character is sent. But as this gave me an element of doubt in my version of the code (given how easily I screwed up the deletion of the wrong line), I connected the PicKit2 back up to the ICSP port, loaded up your version D of the MC code as you have confirmed the code responds to instructions and the PC firmware updater application. The programming of the PIC was confirmed by reading the verified code back into the pickit2 application after relaunch, and then exporting it as a file and then opening that file in an editor and sure enough the code looked the same. So now I'm confident the PIC is programmed with a working version of code. I'm just struggling in finding a way to test it, which given your explanation above may prove difficult. I'll retrace the serial connections now I have the board in front of me, but something is causing the DVM to give strange readings, so I'm guessing that the lines are tied together through resistors, caps or inductors somewhere along the lines rather than straight out from the PIC to the connector pins. I looked at R1, and on board it measures around 6.6K ohms. My battery in the DVM is running low, so I'll remeasure again once I've changed the battery, but its not open, so hasn't blown.

Thanks for the HEX file - if my code doesn't work I'll use the proven one... at least now I know I can program the chip in circuit without issue if I have to re-program it's no big deal

Well the good news is that the PIC was programmed on board using the ICSO header...... I used a DVM on continuity to trace out the pin connections, and yes you are right it's all reversed, pin 1 (indicated by the square pad) is not MCLR - Pin 6 is. Working back from the pad nearest the PIC (pad 6) we have, MCLR, Vdd, Vss, Data, Clk Using the PicKit2 it found the chip, and programmed my version of the code. I'm in the process of rigging up a connection to the PICs serial port to test. Fingers crossed it will see the chip and respond to the firmware updater and those commands....

Morning Archie, I was thinking the same, the updater is looking for two micros, but only one was responding. Thanks for checking the HEQ5 hex code and the detailed explanation. I'm sure in the previous post it said delete the first line, which matches the example in that post. Can you upload your working MC0004 code. Whilst my efforts seemed to work, I would much rather use one that is proven to communicate and respond to the correct commands Also, what are your thoughts on using the ICSP header... would there be any risk to the other chips when MCLR /VPP is taken to 12v ? Malcolm

Archie, Whilst I'm waiting for the board to arrive from Astrogeek (RM not doing such a stirling job this time round... ) I thought I would try and produce an unprotected HEX file for my HEQ5 just in case I should ever need it, and whilst this thread is still fresh in my mind. I downloaded the firmware from SW website, which was already an uncompressed MCF file. Ran the PY script to produce a HEX file (HEQ5.HEX) - I then opened that file in the HEX editor and deleted the first line that has 020000040000FA and saved it as a new file (HEQ5config deleted.HEX). This was then opened in PicFlash, and for some reason it still showed as being code protected. Changes to the code protection settings were made and then saved as a new file (HEQ5config reset.HEX). This file was then loaded back into PicFlash and all the config bits and code protect were correct ( copy protection bits were clear and HS oscillator correct for HS) but when I try and burn the PIC it fails with 41 program errors... If I then load that same code into PicKit2, it programs and verifies without issue.... I can then take the programmed PIC that was programmed using the PicKit2 and place it in the EasyPic 5 dev board, read the PIC back just fine and even verify the code using the PicFlash application... However every attempt to read the firmware level on the pic from Skywatchers firmware loader application fails so I have no real way of knowing if its running or not ( I do wish SW would add a LED to their boards that would flash so you know if the device has a heartbeat and is running - testing would be a lot easier) HEQ5config deleted.hex HEQ5config reset.HEX HEQ5.hex

Morning Archie, Thanks for the info, and for creating the online schematic... I'll take a look

Archie, Can you advise how best to do this (a link to the editor you used if possibly)

Well this is interesting..... With the PIC in the EasyPIC5 dev board programmed, I connected up a FTDI USB - 5v logic serial adaptor to the PIC serial port and loaded up the SW Firmware loader application The result is quite pleasing

I just want to comment on this thread for anyone else following along.... This thread is NOT about trying to circumvent the copy protection in the Skywatcher Firmware. I've posted all my trials and tribulations in trying to get a PIC reprogrammed so you can see just how complicated these things are, and the effort we are putting into getting this board fixed. The intent is to provide a documented thread for others to follow should they find themselves in a similar situation to the OP where their board has been fried and there is no clarity from the agent, UK distributor and even Synta themselves as to compatibility between new and old boards, or if a replacement for the original boards are available. This leaves the OP with the choice of a £200 bill for replacing the existing boards, one of which is perfectly serviceable, or giving up on the goto function, which was the main reason the scope was bought for. The last option is to try and repair the faulty board... which without the help of synta or the UK distributor means we have to resort to reverse engineering..... My thanks to Archie for his assistance in resolving the PIC code issue.... now to get the board back from the OP and reprogram it for him.....

Those errors are reported using the mikroelctronika PicFlash program.... I'm guessing that it was due to the code protection bits.... Anyway I now have been able to program the PICs without errors after following your instructions. I missed the part about loading the converted hex code which had the config bits removed and then exporting it with the PIC selected to generate the config settings, and the re-importing it again....

Yeahhhh.... success !!!!!!!!!! Well as far as I can tell.... having exported the files as instructed and then loaded that back into both PICFLASH and PICKIT2 the code loads, verifies, and can be read back...... I did have to set the OSC to HS (the motor board has a 20mhz xtal on it) but now have two programed PICs Archie, thank you for teaching me these techniques... even at 58 I'm loving the learning curve