Some time ago I asked our intern, Manny, to design an Arduino clone. This was primarily a learning exercise. He’s worked with the Arduino platform one some projects, and created schematic/PCB/firmware for a Microchip PIC based project. This project was designed to combine those experiences to create a more generic tool. I felt the results of his effort were pretty cool, so I thought I’d share some of the concepts here.
I recently completed a software design to control a Keysight digital storage oscilloscope (DSO). The end goal of the software was to initialize oscilloscope settings,
set a trigger, and then make timing measurements from a trigger on one scope channel to an undefined point of a signal on a second scope channel.
The second signal I had to measure was not something that would be available to me during development. This posed a bit of a problem. I knew the signal would be a rising signal between 0-5V, but did not know how complex the signal might be. It could be exponential, a simple ramp, sinusoidal, or some weird combination.
This week in the epic adventure I like to call Thermistor and Thermocouple Temperature Logger Part 2, I took a look at the thermistor portion of my circuit.
Two years ago, I found an issue with the open drain performance of one of the I/O lines of a PIC24FJ32GB002 microcontroller. I got it confirmed from Microchip, but they never actually put out an errata on that behavior. This time, I have found an even larger problem, that I am sure will rise to the level of an official errata.
I was trying to use a PIC24FJ64GC010 microcontroller in a design for a client. The design has a capacitive sensing keypad that has worked well in the past with a slightly different Microchip microcontroller. I moved to the PIC24FJ64GC010 because it had some other features that were necessary for the design. Unfortunately, migrating to the new micro would prove to be problematical. The capacitive keypad was implemented as shown in the schematic below. In order to get the best performance, each button was implemented on its own. In addition, the CTMU output current was routed through the internal op-amp as a voltage follower so that the noise immunity of the keypad would be greater. Little did I know that dragons lurked in this approach.
Problems arose when I started shaking out the PCB. For the life of me I could not get some I/O lines to output a current pulse. The scope capture below shows the problem. The yellow trace shows the output of the op-amp. Every time the current from the I/O goes up, the current on the op-amp should ramp up. The current is turned off and then a different I/O is selected. Every time a button is sampled, the micro would toggle an I/O as shown with the green trace of the scope capture. As can be seen from the scope capture, only 8 current ramps are shown. However, there are 12 toggles on showing that the micro was trying to output current with the CTMU.
At this point, I put on my troubleshooting cap and went to work, because when problem like this arise it is almost always the engineers fault. I individually addressed the I/Os shown in the schematic in digital mode – I could read inputs and set outputs as desired on ALL I/O lines. I could also read analog inputs on all of the I/O lines (which due to the new A/D architecture is a feat in itself and will be detailed in an upcoming blog). I could individually turn on and off the internal pull up resistors. However, I could not make 4 of the I/O lines output CTMU pulses. I even lifted individual I/O pins off of the PCB to ensure that the problem was not somehow related to the PCB layout.
I spent some time trying to cajole the Microchip application engineers that there was a problem and could they help me. After fending off their initial dismissive replies (ie – “try using our sample code”, “it works here”, “have you used our demo board”, “you are overdriving the outputs, they should not clip”, etc), after 2 weeks, I was finally able to convince them to look at the problem for real. I had to send them my hardware. and from there it was easy for them to confirm the problem. Another engineer here was able to initially figure out the pattern that allowed the diagnosis, which is fairly odd:
“The CTMU will NOT output on any A/D that is even and less than 15”. For example, RB4(AN4) will not output CTMU pulses while RB1(AN1) will. Unfortunately for me, I had randomly selected four of the offending analog I/O lines. This was a setback to the schedule and my stress level. However, at least I know I am not crazy and I did everything I could to get the part to work. In order to get the design to work, I needed to reroute the board and leave off these bad I/Os.
Unfortunately, I do not know if this is a family-wide problem, or a problem with any of the new advanced analog micros, or just related to the PIC24FJ64GC010. It will be interesting to see what the errata says. Microchip put out a new errata sheet on 4-20-14 (about 3 weeks after they confirmed the problem), but this issue is not listed.
Above you can see the primary circuitry for the simple temperature and humidity sensor I described last week. The board shown above is part of a client’s design, so there is quite a bit more circuitry than is required for the sensor I described last week.
Last week I discussed my latest project, an accelerometer based dual axis solar tracker (that blog is here). When starting a project its easy to get lost in the details. For example, this project has a whole host of possible control functions and interfaces. I’ve always found it useful to start my work on the schematic and hardware. So that’s what I did.
Since this is an R&D project I decided to use some components I haven’t used before. This design will control a 24VDC brushed motor, and a 12VDC brushed motor. I’m going to use two St Microelectronics PN: VNH3SP30-E. They’re rated for 40V and 30A (although there’s no way they can handle 30A without melting off the PCB). One feature I like about these controllers is that they only need a single PWM channel for proportional control. Two other digital channels are used to provide direction. Here’s a section of the schematic that shows the connections between a PIC16F1789 and two of the motor controllers (click the image for a better view).
In the end, this control system will be used to control our dual axis controller that uses a worm gear for horizontal movement, and a linear actuator for vertical movement. Here’s a photo of the assembly in front of the old college text books we could never bring ourselves to throw away. Both the worm gear and linear actual came with feedback. The worm gear was very expensive and has an encoder on the motor. the linear actuator was pretty cheap and came with a potentiometer that failed in about a month. That was one catalyst for attempting that has the position feedback on the control board via an accelerometer.
The circuit board ended up being about 2.5” x 3.5”. Here’s what the top copper layer looks like. The 6 dots on the upper and lower right-hand side of the board are for mounting automotive style blade fuses.
Here is the column from my bill-of-materials.
There are a couple of interesting findings. First, I have an 8MHz oscillator on the design that has the smallest range of operation (-20C to 70C). I’m actually going to use the internal oscillator available in the microcontroller, and I don’t see clock timing to be an incredibly important issue in this design. I added the oscillator part to the schematic as kind of a back-up plan but don’t plan on using it. So I’ll ignore that problem for now.
The next lowest temp. range part is the PDV-P7002, a photocell I will be using to detect daylight. For a part like this, whose resistance changes with light, I would guess that it goes “out-of-specification” outside of its operating range. I doubt it quits working. I’ll have to research that some more, but since I’m using the photocell as a yes/no type input I can accommodate a wide resistance variance.
That leaves me with some ceramic caps that don’t meet my operating temperature range, and I can certainly select a similar part with an extended temperature range, so I’m probably good there.
I guess there was one other issue. The small metal buttons I have on this design (E-Switch parts) had no temperature rating. I thought that was interesting. These are not the kind of buttons you would use in an outdoor design, but no temperature rating?
And now for a sanity check. Am I really going to run this design between –40C and 85C. Nope. This is R&D, it’ll spend its life in my office. If this were a consulting contract we would design for this temperature but suggest our clients place test fixtures in the intended environment to collect operating data and/or make use of a temperature chamber for extended temperature testing.
That’s as far as I was able to get this week. I’ll try to take some time over Christmas break to order the circuit board. I need to panelize it with some other designs so it doesn’t cost an arm and a leg. Hopefully I can begin writing code in January.
Last week the printed circuit board for the Disco Bike Light project arrived. This allowed me to move from my breadboard prototype circuit to the actual “form-factor” design. If you’re not sure what the Disco Bike Light project is you can look through some of my older blog posts (here’s my last post). The short story is that I wanted to design a flashy, fun, multicolor bike light using an existing bike light’s enclosure.
In last week’s blog I talked about looking into using an accelerometer output as a user interface for the Disco Bike Light design. This week I took the next step of actually implementing a method of detecting taps with an accelerometer and using them as an on-off signal.
For a quick refresher, the Disco Bike Light is a design where I’ve decided to replace the guts of a Schwinn bike light with my own electronics. I wanted more color and more brightness. I put some constraints on myself for the design. One was that I couldn’t destroy the existing bike light in the process of making my new one. For on/off/color control I was left with few options…
Welcome to another edition of “Disco Bike Light: adventures in electronic design”. In last week’s blog I talked a little about the printed-circuit-board (PCB) design and the Lithium battery charging circuit. This week I’ll touch more on the circuit board, and a little bit on the user interface.
In last week’s exciting episode of “Disco Bike Light” I covered some of the issues I had with this electronic design. In summary, I’ve decided to convert my bike light to a multi-color kaleidoscope of mobile joy.