malc-c

I think the warning about the config bits is a read herring - It's down to the fact that I'm using the wrong variant of the chip. Hopefully when you replace both PICs with the corrected code it should work OK

Thanks for the image and clarification.... I did try it with a 16MHz crystal but still couldn't get it to respond. I could program a 16F885, and get that to respond with a 20Mhz crystal, but then if I swapped out the PIC for an 18F2520 and changed crystal to a 16 Mhz one - nothing...... But this is now getting beyond my level of expertise...

I think on this one you may stuck. On all the previous MCF files, the configuration bits (that set the timings, code protect, and basic function setting on the PIC) are included. But the AZ-EQ6 MCF file form the Skywatcher website doesn't appear to have these in the code (as far as I can tell as I get warnings when loading the first conversion of the BIN file to HEX). So we have no idea what are the correct settings for the oscillator, or other configuration settings. This could be why I can't test the code, or it could be that when I import the converted base line HEX file, and then select the device in MPLAB it sets the config bits to values that are default but not correct for the hardware on the board ? It could also be that I'm limited to testing on the 18F2520 as the programmer I have doesn't support the 18F25K20. Anyway, I've attached the first straight conversion from MCF to BIN and then to HEX for you to try as well AZ6.hex

Binary file converted to HEX as requested However I was unable to test as I cannot find the value of crystal the AZ-EQ6 board uses. Tried 20 Mhz which is common on MC003, MC004 and HEQ5 boards but couldn't get a ping back, even tried 16 Mhz which is often a popular value. Downloaded the MCF file as the BIN file you provided resulted in a warning about the configuration bits, but that to had nothing set. Saved the converted HEX file with configuration bits set in MPLAB and it still complained, but loaded and verified the code accordingly. So I'm not sure if the reason it won't respond to :e1 is down to the wrong crystal used which will affect the serial port timings, or that the AZ-EQ6 MCF file Skywatcher provide has been doctored in some way making conversion difficult. If you could advise what timing crystal is used that would help. I tested on an 18F2520 as I don't have any K variant and my breadboard supply is 5v, but as far as I can tell the K version is just the 3.3v version with a few added functions, but code should run on both (I welcome someone to correct me it that is wrong ? - Archie ??) By all means try the attached code and report back AZ-EQ6.hex

No worries, glad my suggestions helped

Not sure why, but the following may help as it works for me Once python has been installed, ensure the scripts, plus the BIN file are in the same folder. Then you need to open the command as administrator, and then navigate to that folder. Then start python by typing py -V before trying to run the command to run the script. You should see the confirmation that python is running as "Python" plus the version number is displayed. Then type in the script parameters For example Hope that helps

Andy, My guess would be the driver for the cable and having it set at 9600 which is set in the PICs firmware. The 115000 speed is for the newer boards that have a USB socket (often found on the new Eq5 / EQ35M and such. Anyway, it's up and running which is the main thing

Andy, glad to hear the two are talking to each other. It would be helpful for anyone following, or any one in the future with similar issues if you could explain what it was that resolved the issue, and if it was related to anything I suggested in that post that took me a good hour to type ! As for the parking position, one way to resolve that was simply be to set up a custom parking position. Place the mount in the desired position, in the Park/Unpak panel of EQMOD (click the spanner under the version number if the settings window has not expanded) click the button with P+ and a window pops up from the top dropdown list select "undifined" and type in a name for it, then click the set button and close the window. Now under the Park/Unpark panel, the new custom park position can be selected from the dropdown list as the default parking position. Now when you unpark the mount the park/unpark button displays the name of the parking position you just created. May not be ideal, but its a workaround

Andy, The good news is that the cable you listed is indeed an EQDIR cable and one that uses FTDI chipset so it should be picked up by windows, if not drivers can be downloaded from the FTDI website. here There are several tests you can do to confirm if the issue is with the com port on the PC / Laptop, or software related. Open up device manager, under Ports (COM & LPT) and you should see the com port assigned to the EQDIR cable when its plugged in. Make a note of this number Right click on the port and select properties, then select the port settings tab Ensure the Bits per second is set to 9600, data bits 9, parity None, stop bits 1 and flow control None Click OK to close, and close Device manager window. Now to check EQMOD setting. From windows Start select all programs and navigate to EQMOD > EQASCOM Select ToolBox Click Driver setup Middle left is the EQMOD port details panel. Set Baud to 9600 Rather than search for the port, click the drop down arrow and select the port number that matched the port shown in device manager In the panel above select SyntaEQ if its not shown. Click OK Power up the mount (with cables connected) Click on Test Connection to launch, EQMOD should launch and display the mount position. If It reports a time out error then we need to investigate further Click the Disconnect button in the Toolbox window to close EQMOD Close the toolbox. The simple way to test the EQDIR cable is to use a thin bit of wire to short the RX and TX pins on the RJ plug. If you hold the RJ45 plug so that the pins are facing you with the spring tab is uppermost, pin 1 is on the left and pin 8 is on the right. You need to short together pins 5 and 6. If the cable follows the default standard for FTDI manufactured VCP this should be the Orange and Yellow wires. This can be done with a short length of wire , or fine nosed tweezers. In order to test the cable download a serial terminal such as Termite from here Once installed, run Termite Click the settings button and in the port settings set the port to the same one noted in Device manager, with the same settings for baud rate (9600) etc Leave the transmitted text to Append CR and local echo and click OK Click Clear In the small window at the bottom type in any text you want but don't click the return arrow just yet Short pins 5 & 6 of the RJ45 plug with the tweezers and then click the return arrow to transmit the text via the EQDIR cable You should see the same text appear in the main screen If you do then this proves the EQDIR cable is working, and it proves the USB port on the PC is working, and that the drivers are OK. Basically what this does is connects to the com port, sends a string of characters to the port which then gets transmitted to the TX wire, which as its connected to the RX wire then sends it back to the com port and the result is echoed in the terminal window. Think of it as a submarine sonar that sends a ping out and it then hears back the echo. If the test of the cable described above works then the issue is with the mount. It would be worth checking that the cables are plugged in correctly between the interface PCB (where the handset and power plugs in) and the mainboard. If that checks out then my git feeling would be that the PICs are fried, or the two 1N4148 diodes have gone open circuit or shorted. It is possible to fix this if the board in your HEQ5 is of the older type with two 16F886 Pic microcontrollers. I've repaired a few boards this way (mainly MC003/04s for Dobs, but also my own HEQ5 board), and the full process is detailed in this post here If the board is one of the newer boards that use nan ARM processor then that is beyond my skill set and you would need to look at obtaining a new board. One other possibility is that the PICs are fine, but the issue is with the power side of the board. This would need testing to ensure 5v, 12v and 33v are present on the various parts of the PCB. If the 5v rail is missing then the PICs won't run (in the case of old boards, the newer one also have a 3.3v rail) If the PICs are not able to run then this too would give the same communications error (it would be like trying to connect to an unpowered mount). Anyway, hope this long post hasn't bored or confused you.... but hopefully given you some things to try to get to the bottom of this

Andy, your post is a bit vague Can you confirm what cable you are using with the HEQ5. it has to be a dedicated EQDIR cable and not a USB to serial adaptor with the supplied PC-DIRECT cable. Whilst the connector on the end of the cable is different (a phone type connector rather than a network cable connector) it has been know that people still try and use this , which then ends up blowing the URART ports on the two microcontrollers on the motor board. Lets hope that isn't the case here. Assuming you are using the correct cable that has been designed for direct connection to the mount, it will need the drivers installed. Windows 10 natively supports FTDI virtual com port drivers, so will install them without issue. But Prolific drivers are not supported ( drivers were dropped way back in 2012), so you would have to search, download and install the correct driver for the cable you have. If the cable has installed correctly then go into device manager to confirm the port settings and number. It needs to be set to 9600 baud speed. If you are still having issues with EQMOD reporting a coms error, and still have the handset to hand, try that and if it reports "no response both axis" then that will confirm that the motor board has been damaged and you either need to purchase a new one, or if you have soldering experience and can pick up a PIC programmer can replace the two 16F886's (if you can find them as there is a shortage of electronic chips worldwide). If the handset works then this proves the motor board is fine, and the communications issue is either the EQDIR cable is faulty, or its software related on the PC. Updating windows to the latest build resolved issues with the sliders (active X components) disappearing, and nothing to do with the communications. If you can report back, with details (not "its fine" or "expected") then it would help us advise further

Reduction in noise, less backlash, smoother running, and higher precision goto's are the main benefits. I was the first to modify an HEQ5 a decade ago (the original test and development thread is probably still on the site somewhere), using off the shelf parts. The drawback was with off the shelf parts it was impossible to match the default ratio to enable it to work with the handset. But as I use EQMO a 4:1 ration was possible, so for me (and those in a similar set up) this worked. Dave form Rowan has his own CNC business and was able to overcome the issue of a small enough motor pulley for the stock gearing by machining it as a single piece form a solid bar of aluminium. The rest is history. Rowan have sold hundreds (possibly 1000's ) of kits since. The one advantage my home built conversion has over the Rowan kit is using a 4:1 ratio the harmonics for PEC are more regular so PEC is an easier process. Here's my original video from 2012

Un modified cameras have IR cut filters in them, which restrict the light in the Ha spectrum that as astrophotographers we would like to record. A fully modified camera typically has all these IR cut filters removed so the sensor received the full wavelength it can detect, in both UV and IR. Sometimes a piece of "glass" is placed across the sensor to protect it from dust etc. The drawback when using a full spectrum camera is that you can end up with bloated stars, with a blue edge to them as the sensor records all the wavelengths. It is therefore advisable to fit a dedicated astro UV/IR filter between the sensor and the subject. These cut out a lot of the spectrum we don't want, but allow the parts we do, such as Ha, and as a result stars appear more natural when processed. But as others have said, its nebula and galaxies that really should be the target, not stars, and they have already suggested some targets. You may find that even without the UV/IR filter, the amount of IR the camera picks up will make for an interesting result.

@Keith Dutton I see what you are saying, and yes there could be a tendency for the panel to crash down into the outside wall if it slipped out of your hands whilst releasing the catches from the inside. Maybe the simple answer is some form of locking system like a pair of padlocks ??

Keith, I was just looking at the pictures again and I have a concern that you may want to discuss with the guys when the return. The two sprung loaded bolts on the drop down section IMO should be on the inside not the outside. Having them on the outside is IMO a security issue as its a simple matter for any yob to pull the bold and lower the section to gain access to the expensive kit inside, even if the door is locked and protected by a traditional magnetic shed lock. Granted where our observatories are concerned the are not as secure as a conservatory or some other buildings, but we don't want to make it easy for opportunistic late night visitor.

Stuart that is a neat solution for housing a remote imaging rig... very nice, and extremely good quality for the money. Love it

Nice looking observatory you have there, very solid indeed. As far as complaining, personally I think you have every right to... but then you gave them the benefit of the doubt, excepted what you were told were the reasons for the delay, and granted it's not been a smooth installation with several return visits which inconvenient to both parties, but at least you are now happier seeing the progress made and the response from HOUK. How much of that was a result of you going public with your original concerns by posting this thread, and any subsequent posts form other HOUK customers or forum members we'll never know. At least any other HOUK customers in similar position can see that the company is still trading, and still fulfilling orders, albeit with some delay which they are doing their best to address (working Sundays !!) Keith, keep us updated with the observatory build. If HOUK do read this thread (and lets face it they know about it) then hopefully they can take on board some of the comments regarding customer care, but I would also like to thank them for responding to you and giving you a really nice functional building. I agree the quality is very high, and with the additional metal work certainly takes this out of the converted shed category. Trust me, with all that automation you are having fitted, it takes imaging / observing to a new level of convenience.... you'll love it

Hi, Yes the same procedure outlined in this thread would be followed. - Rename the file to .BIN, install PYTHON and run the BIN2HEX script, open the resulting HEX file in Microchips MPLAB and turn off the code protect bits and re-export the HEX as the final file. Program two new PICs with the file and then replace the damaged ones. Good luck, and keep us posted

As I said, it's a shame they are so far away... otherwise I would be applying

NO !!! If you use a standard USB to serial adapter between the mount and PC you'll damage the synscan board. An EQDIR cable is wired differently and operates at different voltages. You can use a standard USB to serial adaptor with the supplied PC-DIRECT cable that has a telephone plug on one end and a D-type 9 pin plug on the other between a PC and the handset and then place the handset in PC-Direct mode to control the scope using GSServer or EQMOD. If you want to replace the handset with a direct connection between the mount and PC then an FTDI based EQDIR cable form FLO or RVO (or any other leading astro kit supplier) is required.

Having repaired a handful of motorboards I would love to apply, but the 8 hr 450 mile daily commute would make that impractical Good luck with the search, it seems a great opportunity for someone

Your image isn't clear, but this look to be wrong. The Diode is the wrong way round. The bar on the diode should go to the + on the PCB. In this image it looks like its the reverse.

I think something got lost in google translation there Not an expert, but I think replacing the 1N4148 diodes with 1N4007 rectifying diodes is not a good thing - the two have totally different functionality.

Personally, I would add another £10 to your budget and get a table top telescope like the Celestron FirstScope - Signature Series, which can be had for £59. It will be more stable, give a better image and more likely to keep your child focused rather than frustrated. Magnification isn't the significant figure... it's a theoretical maximum and based on the smallest focal length eyepiece and the focal length of the telescope - in practice this is often unusable. The new telescope also comes with all the benefits of buying new through a renowned retailer.

Manged to grab a few images between the clouds.... 200mm f5 reflector with Baader Solar film (a bit old so could do with replacing) filter. Canon 400D, 200ISO and 1/4000s exposure - colour corrected in Photoshop to remove the purple colouration the filter gives. It was the first time I used the scope in six months...... and all the equipment worked well (surprisingly !!!)

If you can use the SW firmware loader application to upload the BIN files from SW website to the motor board, then the PICs are running fine, and you shouldn't need to try and read them back. There are two versions of the 2.09 firmware listed on the SW website, the one for goto mounts has the option for encoders. I believe this was the BIN file that was converted to HEX for the original fix. As far as I know the code isn't motor board specific so will work on any Dobsonian goto, regardless of it being an MC003 or MC004. The fact that you can use the uploader application to program the PICs means you could try either one of the 2.09 versions. If you have and the scope is still misbehaving then I too am at a loss. The SW communications protocol and the command set that is used on all boards are detailed in the attached PDFs. - The protocol / command set is the same across all motor boards. Testing of the PICs / boards using a serial terminal application is detailed in this thread, where sending the relevant command results in the board returning a value, for example the command for the firmware version :e1 [return] returns the version as a string of numbers. The current V3 firmware is 3.39.15 Is that wat you are running on your V3 handset ? One thing I have no idea what functionality it provides is the three jumper pins, which from Archie's schematic connect in parallel to pins 2,3,4 which are normally tied high via pull up resistors. In the image shown, the jumper takes the pin 2 of both PICs to ground.... you could try removing it all together and seeing if it has any effects, or place it in positions 2 or 3 and see if that makes the mount respond differently ?? - On the MC002 board used in the sysnscan units for EQ3 and EQ5 telescopes, there are two jumpers that are used to configure the board as the gearing is different It maybe, and I'm guessing, that the three way jumper on the MC003 board works in some way to enable or disable the encoders, or to inform the PICs that it's in a 10" DOB or 16" etc ??? Other than that I'm out of my depth....and clueless - Sorry synscanserialcommunicationprotocol_version33.pdf skywatcher_motor_controller_command_set.pdf