malc-c

You have no choice now - the converted HEX file is attached HEQ5b.hex

I would have thought that would have got you in straight away. The only thing I had built at the time was a dodgy sound to light unit that had a high risk of shoving mains up the amps output if the transformer broke down ! - needless to say I didn't mention that at the time. I enjoyed my apprenticeship as we had a supervisor that made sure I got a lot of experience in various departments, from the potting shop, the winding shop through to clean air labs where I worked on assemblies for the space and military projects. I remember one department where a guy drew up a schematic on a sheet of note paper and I was tasked to build it. A couple of hours later i presented a small bit of stripbaord with the components mounted and they hooked it up to power and a screen. I had no idea what it was, nor what it would be used for, but whatever it was worked !! - I later discovered it was some form of upscaling circuit, similar to what you see when CSI zoom in to a pixelated image , press a button and it instantly becomes a detailed picture of the suspects car number plate Taking this slightly off topic, but this was my latest project I started this back in 2009, as a unit that had 4 pulse proportional thermostats in one box. This latest uint has 9 independent stats, one of which is used for an incubator and sends the temperature and humidity over the wifi so it can be viewed in any other device (web browser) on the network. I had a lot of help with streamlining my original code that was ported form PICs to the Arduino platform, but then you learn from example. This unit controls the heating for my hatchling snake rack and incubator. I have two more units (without the screen on the left) maintaining the the environment in the nine vivariums housing my collection of pythons, boas and rat snakes. Anyway, I think we've taken this off topic a tad..... lets see what the owner of this last SW MC board has to report when he gets it back and tests it... fingers crossed it will be good news

Nice to hear that you've enjoyed following this thread. Whilst my interest in electronics started in 1978 ( when I started my electronics apprenticeship with BAe dynamics, so learnt to solder to ministry spec - although my eyesight isn't what it used to be), In my spare time I was making basic oscillators with BC10x transistors for my father-in-laws model railways, and then discovered 4000 CMOS logic devices. It wasn't until the late 90's early 2000's that I started messing about with PICs... Assembly is still way over my head, so when I found you could use BASIC that was the route I followed. In the past couple of years I've now moved over to arduino and other devices that use that version of C++ Whilst I can grasp the basics, It's nice to have Archie onboard and contribute to expand my learning further. His knowledge of SW protocol and communications really helps. I apologies if I go slightly over the top with the posts in this thread, but hopefully it can be used as a reference for anyone contemplating a repair of their motor board. However if they lack the confidence or ability I'm more than welcome to take on the challenge and increase that "goal score "

Couldn't have done it without my wingman Seriously, thanks once again for your input and assistance... I've learnt a lot more about these boards, and how they work.

It won't win any awards for looking pretty... but its functional. - And before anyone asks the resistor is several mm above the board, so won't come into contact with the PCB, it's just the angle the image was taken.. I've since added some insulation to the legs of the diode, and cleaned off the flux with some IPA. All that's left is to pack it up and send it back to the owner

We'll it looks like we've scored another goal in extra time The first thing I did this morning was to re-flash the PICs with the same 209 hex file I originally used. Now as the PICs were soldered onto the PCB and there is no ICSP header or pads I had to solder the five wires directly to each PIC. Once the wires were connected to the programmer the code was uploaded and verified. The process was repeated for the second PIC. I then cut the track between the two pins of the RJ connector where the handset plugs in. In hindsight I should have left it intact and tried the repair / modification first as I later bridged the pins once more. I removed the existing surface mounted diodes and cleaned the pads. I then soldered A 1n4148 signal diodes directly to RC6 / TX pin on each PIC with the lead closest to the bar on the diode attached to the leg of the PIC microcontroller. The other legs of the diodes were then bent and soldered together. A 10k resistor was soldered between the 5v supply and these diodes, with a wire making the connection between the diodes and pin 2 of the Rj socket. I then bridged the two pins to see if this fixed the communications issue, with a view of adding additional wires for the RX pins if this didn't work. It was then a case of taking up to the observatory to hook it up to the PC in PC-direct mode with the SW cable to check that the loader application could read the firmware. I was surprised to see the handset went from "initialising" to the Synta handset version and firmware it was running rather than reporting "both axis no response". I didn't bother to put the handset into PC-Direct mode to check the comms as it was clear the board was now responding to interegation from the handset. To confirm this I grabbed the video camera and shot the video below Now from my experience of repairing these boards that have been damaged through plugging in EQDIR cables it's only the PICs that get damaged. The rest of the components seem unaffected after doing this, so I'm hoping that when the owner receives the board and connects up the motors he'll report back with confirmation that the scope is now fully functional. The question is why do people purchase and use an EQDIR cable to use EQMOD with cobsonians when both are designed to work solely with EQ mounts ! Anyway, it looks like we're at 4-0 now S2630001.MP4

Hi Archie, Thanks for doing that, appreciated. I've just checked the board again using the PC-Direct mode on the handset and firmware uploader and it no longer communicates with the board, so it looked like doing the update I tried yesterday has corrupted the firmware. I'll try soldering a few wires to the PGN / DAT / CLK pins and see if I can program the PICs again, this time in circuit. - Once I've done that and the code verifies I'll do the modifications suggested. Malcolm

Thanks for the notes. My logic was that by segregating what's on the board and running new wires direct it would remove any possible issues with the existing tracks or any hidden damage that is preventing the PICs from communicating. It's 3.30am here, so I'm off to get some sleep, and will take another look later.

Archire, like I said I have no idea what's going on with this board. What diodes would you suggest. 1n4148 or 1n4001 ? What if I cut the tracks completely to isolate the TX and RX pins on the RJ connector and at the PICs, and then wire it like this ? - If using the MCLR pull up is a bad idea I can always connect a 10k to the other side of the resistor which is 5v. This is of course assuming that the updating of the firmware hasn't corrupted the PICs. There is no ICSP header on this board - and I doubt the board would take desoldering the PICs again

Probably going to be in another 4/5 hours... circa 4pm CST - 9pm UT. They haven't cleared the pad yet let alone start loading fuel... that's of course if there is some issue that SpaceX hasn't mentioned, seeing that this has been pushed back each day since Friday. Last night's wet rehearsal wen well (apparently)

IMO, you will be very disappointed. At most you will probably see a few of the bright star clusters, but with a small scope and poor polluted skies you won't see much, if any of the fainter deep sky objects.. To see nebula and other faint galaxies you need a nice dark sky away from city lights and the pollution that goes with it.

Archie, Would modding the board like this work Basically cut the track between the TX and RX pins on the RJ connector, then run fly leads as show (assuming RX on the RJ connect is related to the handset and not the PICs)

Hi all, Well we made progress to a point... but it was one step forward and two steps back... I tried swapping the SMD Diodes with IN4148 signal diodes - still no joy. I tested the original diodes and as far as I could tell with my DVM they were OK, so replaced them back on the board. The next task was to reflow the solder joints on both PICs to make sure there wasn't a dry joint, and checked for any bridges on the solder joints on the links I added. Still the same response. I had received the Ok from the owner to try flashing the firmware using the PC-Direct cable and handset. So I popped up to the observatory, pulled the power lead from my HEQ5 and plugged it into the MC003 board. Connected the handset, plugged in the PC-Direct cable to both the handset and the PC and powered everything up. The Handset displayed the normal "no response" message so it was put into PC-Direct mode. The firmware loader was launched, detected the handset on com 1 and to my suprise reported the firmware version of the motor board ! - Gobsmacked I clicked the MC version button and it cleared and came back with a version 2.9.99. So I proceeded to load up the 2.09 firmware for dobsonian scopes, downloaded direct from the SW download page. It progressed through to 100% for MCU1 then reported a failure. The board was powercycled and I tried again, but this time the firmware updater could not get a ping back from the board. I tried several times to upload the firmware and each time the loader could not connect to the motor controller, so it looks like the update bricked the motorboard Now I no longer have stock of the PICs, and I could order more and program them again, but we could be back at the same stage. Plus every time I remove the PICs there is a risk of more and more pads lifting, and so far I've been lucky that the ones that have lifted have been unconnected, or simple to bridge / repair. The board is circa 15 years old which makes it more fragile, and the attaching of test wires is also having a toll on the board. I have no idea why the handset would not retrieve the board details post initialisation, yet would respond via the handset in PC-direct mode when the uploader application was used.. To be honest this one has now gone beyond my ability of basic diagnosis and changing re-programmed PICs which with later boards have proved to work. I'll return it along with the handset to the owner, who has resided to continue to use the scope manually. So it's more like 4.0 to us, but that last goal was disallowed Unless anyone has some other suggestions.

Archie, thanks for the input. In the last set of images there seems to be data on both PICs TX lines. Where would you suggest I start looking in order to confirm that the PICs are OK and that the switching is working? The scope is a 15 years old Skywatcher 250px flextube with AZ Syncscan GoTo so I've assumed that the same firmware for the Skyliner (2.09) dobsonian as used on the MC04 boards in previous fixes (all dobsonians) would be the correct one to use. I did have one of the SW serial cables (DB9 serial to RJ11) cable which I believe is used to upload firmware to the handset and mount, but as I'm not in a position to be able to cover the cost of a replacement handset if i fried it I'm reluctant to try and update the firmware, and I've already used the last two sets of PICs I had on this board, and due to its age replacing the PICs could end up bricking the board completely as more and more pads lift. So far the ones that have lifted have not traces to them and are not connected. The only other firmware for "AZ goto mount" but also has the same version 2.09. Looking at the EQ6 schematic, which uses separate TX and RX lines, would breaking the track on the PCB between the TX and RX pins and then hot wiring the lines in the same way the EQ6 does using the two diodes on the TX lines work ?

A further update. I connected up both PICs to the anzlizer and got this trace. Here's a close up of the left hand side And the right Just noticed I should have swapped over the wires so that the traces made more sense, IE RX then TX and not vice versa To me this just seems to be echoing back what has been sent, much the same way as simply shorting TX to RX together.....

OK we might be getting somewhere... but I need someone with a little more experience to analyze these results and comment on them as they raise some questions. I hooked up my PC based logic analyzer. It's basic and only samples for 10 seconds at a time, but this is enough to get some idea as to what's happening. One channel connected to the drop pin from the handset. A second to the combined RX/TX pins of the RJ11. The third and fourth to the UART of the first PIC. I set it sampling and plugged in the power. The handset powered up, initialised and then displayed caution, and then both axis no response message This was what was captured It seems to send an initial handset to the PIC, which gets an initial response, as you can see the TX trace responds straight after the data on the TC/RX line is passed through the diode to the RX pin on the PIC.. I'll zoom in a little so you can see in more detail You can see by the traces that some form of data is being sent back form the PIC as the pulse lengths vary suggesting 1's and 0's I then took a further capture after pressing the ESC key twice, forcing the handset to re-initialise. This was the result Now this where things don't seem right. The handset sends data, which then appears to trigger the PIC to respond and says "hello" back. But then sends some more data around 50ms later and this time gets no response. back. My first thought was that with the RX/RX pins commoned at the socket I was simply getting echo back, but looking at the data traces they appear to my untrained eye to be different rather then identical. If this was the case then you would expect the echo each time the data was sent to the TX line, would you not? So why does the second set of pulses get no response ? So... Here's my thinking: The PIC's are programmed correctly and are running fine as the response back after the initial power on / re-initialization they respond with a different byte of data than they receive. The fact that the handset then displays the "alt/dec no response" message would suggest that either it doesn't recognise what it received back, or it's it recognises the result, but it's wrong / incompatible with its firmware The initial "are you there" data gets a response back with "yes", but then for whatever reason (blocking diodes on the TX lines reversing ?) when the handset sends "what version MC are you" the PIC doesn't understand and fails to respond. Now one thing I may have laying around from the time I had my EQ5 mount is the official SW PC direct cable that has a DB9 connector on one end and a JR11 (or 45??) on the other. I thought that I could use the observatory PC as it has a standard serial port and try and reflash the MC with a different firmware using the SW updater software, but there is only one suitable firmware. I've used the same 209 version used on MC04 boards as the MC03 and MC04 look very similar, and it states this is for skyliner goto dobsonian mounts between 8" and 16". Also, I'm not in a position to cover the cost of a new handset should using the cable damage the handset because of any compatibility issues (plus I've never actually used that cable as I built an EQDIR cable within days of getting the mount). Comments and suggestions please...... Edit: the handset reports "Synscan ver 04.37.03"

Hopefully the motor board will be OK. Just plug your handset in and check it still responds and you can move the scope. If there is a problem have a read of this thread.... https://stargazerslounge.com/topic/351363-any-ideas-on-repairing-a-slightly-blown-motor-board/ so far I've managed to fix 3 out of 4 motor boards (mainly for DOBS) plus my on HEQ5 board, and that forth board is still a work in progress!

Archie, images of the MC003 board as promised

Archie, thanks for the input, and I'll have a rumage to see if I can locate one of the logic chips, if not I'll order some form RS. I've contacted the owner who sent me the board and handset and he said he has never had the mount working. The scope came in this state from the original owner, and is circa 15 years old. Either the handset has been very well looked after, or its relatively new as there is hardly a mark on it ! I've opened up the handset to see if there is any means to identify the version... and it's thrown me a curve ball ! Now I know Synta own Celestron, but from googling images of handsets it would seem that all the Celestron synscan handsets have the celestron branding above the LCD screen. This handset is plain other then the word Synscan underneath the LCD suggesting it is a Skywatcher handset. Yet other images for a V4 SW handset also show the same Celestron board inside, unless these handsets are standard and can be programmed with either SW firmware or Celestron firmware I'm really confused ?

One thing that has often popped up on the EQMOD user group is that more than one instances of EQASCOM get launched by various applications, and (more applicable to windows 10) with differing levels of privileges, such as administrator rather than user. That's strange that you get two line entries as well. With my FTDI based EQDIR cable I just get a single port listed in DM

The thing that is confusing me is there is an entry for a USB serial convertor and a USB Serial port, and the top set of images relate to the converter. Most EQDIR cables just show up as a USB serial port with a single line entry in device manager. You could always google the hardware ID (go to the details tab and select hardware ID from the drop down list, then copy and search for the character string. It should list FTDI's site as the main entry and you could try downloading one of the 232TL 5v Drivers and see if that resolves the issue.

Some suggestions for you, assuming that the EQDIR adapter has installed correctly with the right driver (which chipset is displayed under device manager ?) With the EQDIR cable connected directly to the laptop connect it to the mount. Check in device manager that the port is set to the default 9600 baud, 8, no parity. Open up the EQASCOM toolbox from the EQMOD programs folder. Try clicking on the register button to set the driver in association with ASCOM platform. Click on the Driver set up button and in the EQASCOM window select the port that the EQDIR cable is using, followed by OK. Now click the ASCOM connect button, hopefully EQMOD will launch without complaining. If this works, then power down the laptop, disconnect the EQDIR cable from the laptop and then place the active USB cable between the EQDIR cable and the laptop and repeat the above. If this works then it proves the active cable is OK. Powerdown and repeat, but this time install the hub. Again power up and repeat the above. If you get this far and you can still control the mount using the NSWE buttons (with the steps set to 4) then it would prove your hardware set up is OK. To identify if Stellarium is the issue, download and install CdC ( Cartes du Ciel ). Set up the location data based on where in the world you are. Open up the telescope settings and select ASCOM, and then close. Then select Telescope control box and click the select button. In the telescope chooser, select the mount and click OK. Then click on the "connect" button which should then bring up EQMOD and connect to the scope. You can then test by right clicking on a target, select telescope and slew. All being well the scope will start to move to the position of the target. Obviously at this point you've proved all the hardware and a software application that uses the ASCOM platform to communicate the the mount. So this just leaves Stellarium as being the issue. Now I haven't used this application in years, and then you had to download and install a 3rd party plugin to get it to talk to the SW mount via ASCOM and it was flakey back then. So I'm not best to advise how to set this application up and test.

Performed surgery on my 400d a few years back... removed all filters. It's a bit daunting at first, but if you take your time and be careful it's fairly straight forward.

When connecting a DSLR to the 200P you normally remove the lens and use just the body of the camera, so all the questions about self-centering adaptors are irrelevant in this respect as they are not required. You basically attache the T-ring to the thread of the focuser and then the body of the camera to the T-mount. This in effects turns the 200P into a 1000mm f5 telephoto lens. With regards to filters, again as you are connecting the camera body direct to the scope a normal moon filter designed to screw into a 1.25" eyepiece won't be of any used (other than for visual use when you remove the camera body). You control contrast via the exposure (to a degree) and make any corrections for brightness in post processing (such as photoshop or GIMP). There are however projection eyepieces that are in essence an eyepiece, draw tube and T mount in one https://www.365astronomy.com/1.25-40mm-DigiScoping-Camera-Adapter-Projection-and-PhotoEyepiece.html. I've never used one, so can't comment on how well they perform and the type of image you'll get. Regarding the 2" to 1.25" adapter, have a search for self centreing adapters - Antares produce a nice unit. These work by expanding their sides when you twist the ring at the top, clamping both the 1.25" eyepiece centrally and theadapter centrally in the focuser. But this would only be required for visual observing, attaching a CCdD camera that resemble normal eyepieces, and collimating devices, and not required if you use the direct DSLR connection method

Well it looks like this is one board that is just not repairable. When the owner received the board back it still displayed the "both axis not present" message, so I persuaded him to send the board back to me and include the handset so I could test the repair. Well this was received today and I've spent best part of the day having fun trying to resolve this boards problems. The first thing to do was to power up the board using a Meanwell 12v PSU and see if anything was getting warm, which proved negative, so then it was out with the test meter. I checked that 5v was getting to the two microcontrollers, which it was, so that was a good sign that the regulator was still OK. I then spent a few moments tracing out the connections between the handset port and the two TX and RX lines, which wasn't straightforward as it would seem due to the way the two serial ports are connected to the same pins, plus the board is multi layered so sometimes a component would connect to a via that didn't connect to a trace on the top or bottom of the board which makes things difficult. Anyway, after several hours of testing, tracing and remaining a few jumper wires I would still get the same error message on the handset. Not having the schematic, or service manual (assuming it may exist) really meant I was just having "educated" guesses as to possible things to try. In the end I bit the bullet and cut the old PICs off the board and removed the legs, being as careful as I could not to damage any additional pads. Only one broke, but that was easy to add a link to after the replacement PIC had been soldered back in place. Two new PICs were programmed with the Dobsonian firmware code, verified and then soldered back into place. Connections were tested to make sure that each leg that had traces (I had taken photos before) made contact with the VIA or component where required, and then powered on the board and checked the voltages on each pin matched the ones I had noted down before the PICs were removed. Pleased to say the were the same, so this would suggest that the soldering was good. But plugging the handset in gave the same message. I'm still going to try a few things... but my gut feeling is that whatever the previous owner did to this mount when they tried to repair it (presumably then selling it as it no longer worked) has done more damage than just blowing the original PICs. Stay tuned....