JorgeST

The intent is to maintain form, fit and function with the existing board. To that end, the 'tentative' outline of the PCB (and hopefully the connector locations) will be in the same places as the current board. The same applies for the mounting holes. Preserving 'real-estate' is a must. The reason for the micro-USB is that I have no intention of connecting a USB cable directly to the board. I will use an Adafruit cable that "converts" from micro-USB to USB type B. I sent a link before. See it here... https://www.adafruit.com/product/937 I will mount the USB Type B connector on the side of the controller housing. As per the regulator: the 7805 and in general all analog regulators have two basic drawbacks: A: Heath dissipation: The analog regulators follow Ohms law and dissipate heat as a product of the voltage drop across the shunt times the current flowing through it. B: Efficiency: Actual battery life depends on load current and battery voltage over time. Efficiency is low if the difference between input and output voltages is large (Vin-Vout = 12V - 5V = 7V @ 110 mA) I am using a switching regulator. Three reasons: they do better that linear ones for the reasons stated above. In this case I selected one with a quiescent current big enough where the efficiency will approach 87%. Not spectacular but good enough. The third reason is that the environment is particularly noisy (electrically speaking that is) where I plotted the induced noise spikes of the motors against the baseline noise of a lab power supply and got some 63 dB above the said noise floor. Does it work anyway? Clearly. Can be improved? Absolutely. Does it impact the price? Yes! then again I will think is worth it. Finally it is an isolated converter; thus, the return ground path is not at the POL but at the source, which makes for a significant improvement in EMI and EMC. I know most hobbyists do not care but hey! I design avionics for a living. I am a pain about these things. 😆 The differential mode EMI filter is there to reduce noise at the handheld, thereby the two-by-one decade filter in reverse order. Since magnetic flux flows inside the ferrite core, common mode choke coils work as an inductor against common mode current. Accordingly, using a common mode choke coil provides larger impedance against common mode current and is more effective for common mode noise suppression Thank you for the Synta papers. I now have what I need to test the interface at will and learn about the protocol. This is turning to be a lot of fun! I get to do real work again!

Good progress today. Schematic is almost ready for a detailed design review (see attached). Take a look and let me know of any comment, ideas or additions (or subtractions 🙂 ) MC003_Discovery.pdf

All, The attached PDF has a basic block diagram of an updated board preliminary design. Please be mindful that every new design efforts easily goes into 'feature creep' and... then it never ends. Let us keep it simple. Main changes are USB input (PC) and handheld controller inputs (self disciplined; if you connect the USB it will ignore the HC). It will also use a more modern (aka available) motor bridge. The comparators are shown for clarity but I will not use an LM324 for it. There are FAR better choices. Some glue logic is not shown but I will write a Hardware Design Description to explain it all (as time permits) The power supply will be made far more robust and I assure you I will make AMPLE provision to design against accidental "screwups" like mine. Feel free to ask questions. The overall idea (once I figure the bootloader issue) is that any existing firmware can be loaded into this architecture and function just the same. I will publish everything under an open source license so no restrictions to use or change/improve Ideally the PCB should have the SAME dimensions and mounting hole locations and the connectors in the same place with an allowance for the USB probably as a small 4-pin JST or Molex wired to the outside via something like this: https://www.adafruit.com/product/937 I have a real job so progress will not be the same as a full time task but after so many years not doing design but management, this effort will be cathartic 🙂 MC_Block_Diagram.pdf

Replied via (what I believe was) the forum's PM I also got a hold of the Microchip FAE that serves my employer. I asked for her help and she say there might be a few lingering around someplace. My company expend more that > $400K every year with Microchip so I am sure she'll try to find a few. I'll keep you informed. Meanwhile I am putting together the means to program the SOIC package. I have the software and hardware tools, also I just ordered 2 of these: http://www.logicalsys.com/painfo-vpasp-vb.asp?adapter=pa28so1-08-6 to make a programmer Those are 28 pin SOIC to DIP with a ZIF (Zero Insertion Force) so the PICS can be easily programmed without soldering anything In the meantime I will start a complete analysis of the original board and I will trace every connection on the board to extract an schematic. At first glance the MC003 device appears to be quite simple. 1. It utilizes each PIC16F886' counter timer to generate a variable PWM 2. On half the bridge is used for each motor. The Inputs 1 and 2 (or 3 and 4) are used to set direction. The enable gets the PWM which based on duty cycle integrates the voltage applied over the motor therefore providing 'velocity' 3. The 74LS14 (a non inverter Schmitt Triger buffer) interfaces the PIC pins (which cannot supply a lot of current) to the half bridge 4. The LM324 are used as comparators for the encoders (2 for A/B channels at the motor clearly used for velocity and direction - and possibly to detect stalling), and the BIG CHUNKY one which is a simple single-channel in place to provide precise positioning (I imagine it to be either 1024, 2048 ticks or some power of two. I need to find out the exact tick count for each encoder. The small ones (at the motors) are easy. For the big one I have a plan to using a logic analyzer, a small black mask and some MATLAB code In short, I got really unhappy that Orion is of no help so I decide to do-it-myself. If they just sell me the board I would move on. But know I am [removed word]! The only caveat is the bootloader; but I'd bet even money it is based on the one provided with the CCS compiler. A little experimentation might be in order. Besides I get to do some real work again, not just managing 🙂 🙂 I'll keep you posted.

Malcolm, Thank you for the reply. I also sent you a Skype invite in addition to the email I sent early Friday January 28 Best,

Thank you Malcolm. Very grateful for pointing me in the right direction. I do in fact have access to an entire suite of rework tools. The PIC(s) are another story. Digikey, Mouser, Newark, Future, et. al. show 0 stock. Microchipdirect shows 30 April. Nonetheless I will reach out to the Microchip FAE and and ask for her help. Let's see what happens. The diodes that isolate the Tx lines are also blown. Those are widely available (1N914) but I will replace them with a small-signal Schottky diode (30V @ 100mA). There is no reason to drop .70V across at 2mA. The SD107WS-7-F exhibits only 300 mV at 2 mA when forward biased. If I repair the controller, I also plan to design a fully bidirectional galvanic isolation stage for it to completely isolate the mount-based electronics from any 'electrical disturbance' (aka self inflicted pain), so this problem NEVER happens again. I will place PDF schematics, BOM and the PCB Gerbers for everyone to implement, and make it available in this thread. Did you see my email reply to you about TFS? Thanks again

I apologize in advance if this is not the right forum. Please let me know and I will delete the post and place it in the correct forum. I am in great need of schematics for "motor controller made by "Synta" (aka SkyWatcher, aka Orion), commonly employed in the GoTo Dobsonians. This particular version is the MC003 Rev. C circa 2010 I had a 'sad' accident with mine and I must replace the uControllers and figure out a bootloader to reload the firmware. Any help will be greatly appreciated. I would prefer not to reverse engineer the entire controller and just get the schematic outright. Thanks,

All, I own an Orion XT12g with a blown motor encoder - my doing of course. Orion is no help but I found a product from astro-gadget.net that 'might' restore some of the functionality. A piece of information I need is the one that pertains to the number of 'ticks' per revolution for the encoders attached to each 'axis' of the scope. Note: I am not referring to the encoders used in the motors (they also have those) which are low resolution but the ones on the axes themselves. The said encoders do not have an index mark which would the task trivial by connecting to entire contraption a logic analyzer with deep memory. I would be very grateful if someone has data on these encoders I can add pictures if that help. Thank you in advance