malc-c

Archie, I still get errors when programming the PIC using the MC004ee.hex file (53 program errors - 0 ID). I also notice that having removed all the config settings that the Oscillator settings changed as well. Setting this back to HS made no difference - the code still failed to program. However, when the same code was loaded into PicKit2, and whilst it too complained about having no config bits set... it did program, and verify and can be read back...... but with no config setting being programmed then is there a chance that the code won't function correctly as the wrong Osc settings have been set ?

I'll give that a go. In the PicFlash I originally tried changing the calibration and code / write protect to off and none - but hadn't edited the HEX file.... I also tried changing bit 6 in the PicKit2 settings to disable code protect of programming memory and that didn't work.... I'll give your suggestion a go and report back....

I followed your instructions, running from the command prompt. However rather than getting the "Done!" message I was prompted to enter the paths for the source and destination again, which resulted in the same permission error. Only this time it did produce a 1K hex file... full of 3FFF at each location. I think it was this confusion that has resulted in me effectively programming a blank PIC in the first instance.... After a bit of faffing around I managed to get it to work.... using the py script from your zipfile. This produced a 20k hex code with data (see attached). However when this is loaded into my PicFlash programmer the programming fails with the same 53 program and 4 ID errors. Loading the 20k hEX file into PicKit2 gives the same warning about the code being too large for the device - it also shows the code is protected (as it does in picflash).

OK, just to rule out an issue with my PicFlash programmer I installed my PICKit2. With the PIC in the breadboard and the PicKit2 programmer attached I loaded up the code from the post on page 3 and received a warning that the code is too large for the device... but when instructed to program the chip it reported a successful programing. But verification failed. I get the same results with the sample EQ6 file contained in the zip file. If the device is read after a "successful" program the program memory is just 0000 in each location Any ideas Archie ?

And along the same theme here one with the pic removed as a few tracks and vias are under the device

Archie, I could really do with some help here. I have installed python, and executing the scripts in that zip file launched a CMD like box asking for the path to the BIN file, which was copied and pasted against the prompt. I hit return and pointed it to the folder where to put the HEX file and hit enter. Some text was displayed and then the box was closed. On checking the path for the HEX file, the folder was empty. I had to resort to recording the screen in order to see what the messages were... I've tried locating the output folder directly on the C drive and it still have the same error... Any ideas Placing the BIN file in the PUBLIC folder (where everyone has permissions) and then opening the script in the Python IDE and running it from there also results in the same error, so I don't think its a windows user permission issue Even running the IDE as Administrator has the same issue

I think I've found the possible error.... I don't think the PIC has been programmed with the right code. I'll drop the OP a PM...

Archie, When I loaded the HEX code the programmer fuses are set by the config bits in the code when the code is loaded into the application. I'm wondering if, for example that these bits needed to be changed, and as a result the code as programmed has not programmed correctly. Now this may be down to me messing with bootloaders the other day, but I just erased and blanked the PIC, loaded the code which set the fuses shown in the attached image, but then errored with 53 errors and 4 IDs... Clicking the CODE button shows the HEX as per attached image.... Originally the chip I programmed and mounted on the PCB programmed without issue.... but it's raised an element of doubt as to the the replacement PIC being incorrectly programmed causing it not to run....(for arguments sake say the oscillator setting should be HS_PPL and it gets set to HS)

I was under the impression it was vice-versa. - so that would mean the EQDIR cable was connected to the socket where the link cable would go.... hence how 12v was placed on the TX line, and how the AZ board was not connected at the time. My apologies

OK, to the best of my abilities using the images provided (including one I took with the PIC removed which helped a lot) this is what I came up with for the serial connections. I may have missed a connection, it was difficult working from the images having to remember the flip them when tracing, so I'm not 100% this is accurate - I'm sure I must have missed a link somewhere I'm sure AstroGeek can have better luck confirming this as he has the board in front of him. The links Lx are shown as looped wires Pins 6 and 8 of the handset may not be linked - hard to tell, but three may be some webbing around pin 6 to the same copper fill as pin 8 ?

Archie, programming the PIC using the EasyPic5 board took a couple of seconds to program and verify

This bit is will fail.... because the new PIC doesn't contain the bootloader which gets interrogated by the PC application. I proved this point yesterday by having a USB to 5v TTL serial convertor connected to a DIL version of the chip in my EasyPIC5 dev board (yeah its old, but does the job ) - Uploaded the HEX files you kindly provided and then tried to re-upload the official download using the SW PC application. On each occasion the MC board could not be found. I tried a few of the bootloaders available on the net and again the PC app would not recognise the chip. My guess is that SW have written their own bootloader to work with their PC application so that the correct handshake is given and received.

Thanks for the input... I believe Astro-Geek actually ordered one from them, only to find out it was a blank board with no components - this is the case with newer version as it seems that rather than use two identical boards as is the case now, newer versions have all the components on one main board with a breakout AZ daughterboard that just has connectors on for the AZ motor and encoders. The board was sent back as it was mis sold as their website (still) shows the older revision F board that is the same as the faulty one. My HEQ5 board was an easy fix because it was the power supply that surged and blew the caps.... How did you blow your HEQ5 with a EQDir cable... From memory only three cables need to be connected to the mount from the FTDI chip, TX/RX/GND ? Seems a common issue where some EQDIR cables stick 12v up the TX pin on the connector... I like the idea on setting up some sort of wiki... but it would be cool if we could find someone who knows how these boards work. I know the guys over on the EQMOD group (Chris in particular) knows the command set inside out in order to develop EQASCOM / EQMOD, but how the boards process that and route commands etc is going to be a stumbling block. Normal commercial practice when designing products is to try and standardise the PCB component listings where possible, so my guess is that Synta will use the same PICs, same driver chips and same basic communications circuits for the two types of systems they employ. By that I mean where DC motors and encoders are used, such as in the goto dobsonian range of scopes, they will all use the same components, likewise where stepper motors are used as in the HEQ5 / EQ6 the motor control boards will all use the same components. It seems the PIC used is the same irrespective of the type of controller used. So my theory is that if you reverse engineered say the communications side of things on one board it would be the same for all of them. The only real difference between boards will be the firmware as that would need to be specific to the gear ratios and equipment fitted, and possibly matched to the firmware on the supplied handset. If you have the skills to produce a working schematic by reverse engineering your board then please get the ball rolling

Well we tried... I was limited to how much testing I could do without any handset, and having an HEQ5 didn't want to repeat the mishap by connecting my EQDir cable to the board ! Just to add to the summary Astro-Geek has listed. He has replaced the three other chips on the board, and the PIC that I programmed verified that the code Archie made available was loaded correctly. The attempt to upload the MC firmware via the PC application and hand controller crashed after updating MCU1, which may be due to the same issue as why the controller freezes when the ALT buttons are pressed, or it might be due to the lack of a bootloader (it's anyone's guess). But assuming that the original PIC was damaged, the replacement should have worked if other components on the board haven't failed. This leads me to believe that one or more of the discrete components may be aiding and abetting the issue. It's been both interesting and frustrating trying to get this resolved, but at least now OVL have had it confirmed that these boards are still available form Skywatcher, even though the lead time means it will be approaching winter by the time it gets here If anyone has any other suggestions, please feel free to jump in

Granted it would be much cheaper, but for anyone contemplating this might be put off by spending £30 on diodes, only to have 98 of them left over. Plus his facebook page gives the impression this service is run as a business, so could be charging more than the 32p each diode costs. I appreciate it's a personal transaction, hence the statement of a ballpark figure, but respect that it may be something you don't want to disclose. I agree with your comments about the older boards being hard to source. I'm involved in trying to fix a board for a Dob, which uses two identical boards, and the owner has found it impossible to get a decisive answer as to the compatibility between older boards and the new one with wi-fi for the reasons you mention... It's really disappointing to see manufactures no longer providing spares for their products that are less than two year old. Anyway, glad to hear your board is fixed and its given your scope another lease of life

That's pleasing to hear. For the benefit of anyone else requiring a repair could you advise of the costs involved (ballpark figure would do, no need for a breakdown of costs) just to allow them to compare the cost of repair against replacement. I love the way this community comes together to help fix these mounts in this throw away world we live in.

Sod the neighbours, I mean with the UK weather it's only going to be a couple of times a year It's nice to see so many new Skywatcher mounts coming factory fitted with belt drives, they make a lot of difference to the noise levels these mounts make when slewing at full rate, it was this and the better performance (reduced backlash) that led to my experimentation with converting my HEQ5 to belt drive many years ago (around 2012 if I remember). Rowan engineering then took this a stage further to make the kits on the market now. Edit: - Just found the original post from October 2011 https://stargazerslounge.com/topic/121114-heq5-experiments-with-belt-drive/ Now if you want a noisy mount, the old Celestron CG5 used be called the coffee grinder.... for good reason ! In terms of noise... whilst my mount is quiet, and from the location in the observatory wouldn't wake the neighbours... setting the alarm on the observatory at 3am probably does

I know... its not as if I am programming PICs and reverse engineering their boards or anything... Well even though it was a lash up, I was able to program the PIC and replace the old one, with only one casualty which was fixed with a link wire. The only way to know if this has worked is to send the board back to Astro-geek and let him hook it back up with the AZ board and see if its worked. There are of course many "ifs".... Hopefully Archies's ripping of the code worked, hopefully the upload to the new pic works (it was verified and came back as a match), and hopefully none of the discrete components have blown internally that prevent communications between PIC and handset.... Don't touch that dial... we'll be right back

Just think of it as Kama.... when my first HEQ5 board failed I had no idea how to fix, so got stung £100 for a new board. When that failed (again) I reached out to the forum and was given contact details of someone who might help, and the net result was the board was fixed for the cost of a couple of small capacitors.... So if I can do the same for anyone else then I'll try. It's also been an interesting challenge to resolve this one, and I find it all a lot of fun... It does show just how well this forum gels together though. Having got you to replace all the chips other than the PIC and we then came up to that hurdle of how to code the PIC with the downloadable firmware. Archie with his expertise in coding tools jumped in and we now have a possible solution. Anyway hopefully the PICs will be here soon, as will the board and then I can report back with an update.

I'm downloading them now, before the moderators remove them as we are borderlining on hacking SW copy protection of their firmware The good news is that the OP is sending me the faulty board for me to swap the PIC over, so I get to play and check it over. What really sucks about this issue is the lack of support and assistance from Skywatcher and their UK and US representatives. They either fail to respond to emails, or when they do they don't have any answers, which for a sole distributor of a technical product is appalling. The OP has been waiting days for a reply to his mail after they requested photos (which he had already sent) and is still waiting to see if in the event we fail to fix his existing motor board, if they are still able to source a replacement as all the new scopes come with "upgraded" motor boards, and then there is the issue of backward compatibility with his working AZ motor board. These points remain unanswered. Archie, many thanks for your help here... being able to get the HEX code from inside the wrapper was the one stumbling block that was holding this repair back... now we can move forward and hopefully by this time next week the OP will have a working board back in his scope.

I've had it confirmed by Astro-geek... Pic have been ordered, hopefully here tomorrow. I have a PCB from an old project that I used an ICSP header to program a 28 pin PIC in the same package so should be a "simple" case of holding the chip to the pads and squirt the HEX (which now loades without issue to the DIP version of the 16F886) to the PIC.... At least if this fails we've tried everything we can... all magor chips will have been replaced, and the OP has checked voltages against the known working board... if this doesn't work then there is little else we could do other than remove and test every SMD left on the board......

Archie, I have some 16F866's in my hobby box (DIL versions but would do for testing). The converted code loads, but when I burn it to the PIC it fails with this message. The programmer can identify the PIC, erase it / blank it etc but it just won't upload... any ideas ? Scrub that.... not sure what i reset but itn uploaded without error that time !!

That loads into the PicFlash - Just need to get the PIC and get hold of the board from the OP (or see if he's comfortable with replacing the PIC once programmed Thanks mate for all your help....