标签: potentiometers

In part 1 of this blog series, I gave an overview of the PICAXE system and did some BASIC programming of my chip. In part 2 , we looked at using the simulate" and debug functions, and we considered the analogue-to-digital converter, pulse-width modulation, and the one-line display options offered by the PICAXE. I also mentioned the Dallas-Maxim 18B20 digital temperature sensor, and we discussed how the PICAXE's READTEMP command makes using this sensor really easy. In fact, the DS18B20 is just one of a family of one-wire devices that support bidirectional communication with an MCU using a single wire. They include sensors, EEPROMs, digital potentiometers, and serial number chips, including the Button devices that look like watch batteries (more on these later). The PICAXE makes it easy to use all these devices with the OWIN, OWOUT, and read serial number (READOWSN) commands, but you would still require four lines of code just to get the basic 12bit value out of a DS18B20. The READTEMP command does all this in one line, along with truncating the 12bit resolution (0.0625-degree) value to a handy eight-bit (one-degree) resolution value. You can also access the full 12bit value using the READTEMP12 command. Thus, my first task was to hook a DS18B20 up to my PICAXE and start reading it. Yet again, I proved that electronics offers unparalleled opportunities for making a chump of oneself. I failed to notice that the DS18B20 requires a 4.7KΩ pullup resistor on the data line. This is clearly shown in the schematic diagram on the READTEMP page in the manual, along with a pinout of the IC. My reluctance to read the farcical manual meant that I kept getting a temperature of 0 degrees. Along the way, I moved one of the connections, which meant I still failed to get a reading when I finally put in the 4.7KΩ resistor. Finally, I sorted things out and managed to obtain a temperature reading of 24 degrees. The DS18B20 reads in Celsius (Centigrade), which is fine for us civilized types. If you want your readings in Fahrenheit, you will have to perform a conversion in software. The DS18B20 offers some fancy features, including alarms and built-in serial numbers, so that you can put many of them on one line and address them individually. However, the basic READTEMP and READTEMP12 commands don't access these features. You could do so yourself using the one-wire commands if you wish. Of course, the huge bonus with the DS18B20 is that, being digital, you can put it on the end of a long wire. As long as you can still talk to it, you won't have any worries about analogue voltage drop or noise altering your reading. I have a couple of indoor-outdoor electronic thermometers that I bought at a Tandy in Paris years ago when I found them on special offer. I wondered if I could duplicate their functions—such as stored minimum and maximum readings—with my DS18B20s. Once I got one connected correctly, it was a simple matter to connect the second and get my display to give me two readings. The accuracy of the DS18B20 is half a degree. I switched from READTEMP to READTEMP12 to obtain the full 12bit value. Initially, I just displayed the decimal version of the 12 bits. The readings from the two sensors were always within one count of each other. The format of the 12bit data—once you have it in a word variable—is SSSSSTTT TTTTFFFF, where S is the sign bit (1 = negative), T is the integer of the temperature (you get this part with the basic READTEMP command), and F is the fractional part (one count = 1/16 degree = 0.0625 degrees). However, this value is in two's complement format, so negative temperatures tend to look very strange. It's been a long time since I had anything to do with two's complements, so a reference to Max Maxfield's excellent book Bebop to the Boolean Boogie was necessary. This told me that I had to take the TTT TTTTFFFF portion of the value and subtract it from 1000 00000000 to get the number right. I soon had my system displaying two temperatures. I got the FFFF part to display 0.X degrees by dividing it by 25, which isn't absolutely correct, but it's near enough for what I wanted. As you can see below, I've mounted my PICAXE board, the OLED display, and a small breadboard on an old modem case to make it a bit easier for me to play around with things.   Two things are apparent from the above image. First, I'd just zapped the Temp1 sensor with Freezit Spray; that's why this sensor is displaying such a low value. Second, my breadboards are not as bodacious as Max's. I experimented with storing maximum and minimum temperature values. With two's complement representations and possible negative values, this was not as easy as one might hope (at least, not for me). The DS18B20 works from -55 to +125°C, so I added 50*16 = 800 to the raw value to bring all possible temperatures into positive territory. Why *16? The first four bits represent the fractional value. I could then ignore anything over 175*16, compare the current values with those stored for each sensor on switchon, and store them if they were above or below previously stored values. I eventually got this working, but I didn't spend too long on it, because I was keen to move on to other things. All the one-wire devices have a built-in 64bit serial number, which is composed of an eight-bit device type, a 48bit unique serial number, and an eight-bit checksum value. The PICAXE's READOWSN command reads this serial number for you and puts the results into the byte variables b6 (device type), b7-b12 (serial number), and b13 (checksum). The sole purpose of Dallas-Maxim's DS1990A is to act as an electronic key for security systems. This device looks like an old mercury camera battery, and you can get a key fob holder for it. As it happens, my employer has an office in Sydney, and the building access used to employ these devices. There were small receptacles for them at the entrance to the car park, in the lifts (elevators), etc. The company has since changed to a card-based system, but I still have the key fob we used to use. I thought I would try and read this using the READOWSN command. It would be possible to display all these variables on my OLED display, but the easiest way to see them is to execute the DEBUG command. This brings up a window on your PC showing the values of all the variables at the time the DEBUG command was run. Imagine if you made a small program like this.   As soon as a device is detected (i.e., the b6 value is nonzero), the system will show you all the values in the debug window. First, I used my DS18B20 temperature sensors and read the different serial numbers from them. Next, I tried reading my DS1990A key. Straight away, I got a different set of values. Incidentally, the DS1990As are truly one-wire (and ground) devices; unlike the DS18B20s, they don't need a positive supply. They are connected as illustrated below.   I did not have the correct receptacle for the DS1990A, so I used a couple of judiciously shaped wires on my breadboard, which worked just fine. My results were as follows (values are in decimal).   You can see that the b6 (device type) variable is the same for the two DS18B20 temp sensors but different for the DS1990A button. The READOWSN command uses a lot of variables, and comparing with a list of OK numbers a byte at a time (not to mention generating the checksum if you really wanted to be secure) would be a pain, but you could do it and make your own security system. You can buy the receptacles and DS1990A key-ring units (and a whole kit with board, button, and receptacle) from PICAXE. Dallas-Maxim also makes a button that has a serial number, a real-time clock, a temperature sensor, and a lithium battery. It can log the temperature at programmable intervals. This is the DS1921 , and PICAXE also make a kit with it—very tasty stuff. Finally, an answer to a question I had asked myself, and which reader Antedeluvian asked in the comments on part 1: "Can you run assembly language routines on the PICAXE?" The answer is no. Think of the PICAXE as a Microchip PIC with a BASIC operating system pre-loaded (the company calls this the Bootloader, but I think it's fair to say it's a bit more than that). This Bootloader is stored in the PIC's on-chip Flash memory. Some of this memory, along with other types of on-chip memory, is available to PICAXE users, but access is very closely controlled, so that you cannot overwrite the PICAXE code. If the company allowed you to run assembler (machine code), you'd have unfettered access to all memory areas of the chip, and the likelihood of someone like me mistakenly overwriting something would be fairly high. It's important to remember that one of the PICAXE's prime raisons d'etre is to be an educational tool. All of us were students once, and we can remember how easy it is to cause havoc in the classroom. You can use all the chip's spare memory (via PEEK/POKE and other commands), but PICAXE doesn't let you get to the bits that would cause problems. Also, it takes pains to point out that, if you use a PIC programmer on a PICAXE chip, it goes back to being a PIC, not a PICAXE, and you'll have to buy a new one. You cannot get the PICAXE code to reprogram it yourself, either. I think the PICAXE is a pathway to C or assembler, if you want to go there, but it is not in itself a way to learn these tools. In my next column, I will look at how the PICAXE handles I2C devices. I've already started playing with them. As usual, the PICAXE makes using them really easy. In the meantime, do you have any questions so far?   David Ashton Jack of All Trades  

Well, I'm quite pleased to inform everyone that things are racing along with regard to my Pedagogical and Phantasmagorical Inamorata Prognostication Engine project . I have all sorts of amazing news to share, plus I could do with some advice. Let's start with the current state-of-play regarding the layout of the control panel as illustrated below. As you may recall, there are going to be five potentiometers (the second column from the left in the upper portion of the panel). These will be used to input baseline data values concerning one's inamorata, including things like personality and overall mood and disposition.   Surrounding each potentiometer will be 16 tri-colour LEDs, and it's the way in which these LEDs are used that requires your advice. But first I have some mega-cool news; based on a suggestion from my chum, Rick Curl, I've decided to use motorized potentiometers as illustrated below:   These little beauties are Bourns 10K Linear Potentiometers (part number 652-PRM162K420K103B1 from Mouser Electronics). First I ordered one to check it out. This little beauty arrived just a few minutes ago as I pen these words. We immediately whipped it up on the testbench and it works perfectly. The geared motor is incredibly quiet and the potentiometer turns very smoothly, so I've just placed a follow-up order for the remaining four units. The idea is that if one's inamorata should take it into her mind to vary any of the baseline settings you've established, the other potentiometers will automatically change to compensate (a few minutes later they will all return to their original settings). You have to admit that this is rather clever. As an aside, the toggle switches I'm using are little antique rascals with small white bobbles on the ends of their actuators as illustrated below. Generally speaking, these switches look really amazing, except for the part that will be bolted to the front panel, but I have a solution...   I bounced over to the plumbing section of my local Lowes hardware store and found a dome-shaped copper fitting as shown in the image above. I purchased a bunch of these "domes"—one for each toggle switch on the front panel. I'm planning on chopping the lower segment off each dome and milling a slit in the top to accommodate the switch's actuator. I'm also going to "age" both the main brass panel and these copper domes so they won't look quite so shiny; the Steampunk look I'm aiming for is something that wouldn't have appeared out of place in a Victorian setting (apart from the pulsing LEDs, of course). If you compare the latest rendition of the front panel to the original version, you will observe the elaboration of one of the elements—the multi-push-button switch assembly in the lower middle of the upper panel (I only recently took delivery of this little scamp). This is an antique telephone switch assembly as illustrated below:   This looks and feels really great. The only problem is the black "JKL 5," "MNO 6," PRS 7," etc. annotations on the top of the white buttons as illustrated below:   As far as I can tell, these annotations aren't embossed into the buttons, but are instead printed onto them (although I could be wrong). Somehow I have to remove or cover these annotations without negatively affecting the "character" of the assembly. Do you have any suggestions? Moving on... As you may recall, each toggle switch and momentary pushbutton is going to have two associated tri-colour LEDs as illustrated below. These are going to be implemented using Adafruit's NeoPixels, although—at the time of this writing—I've not yet decided whether to chop individual pixels off a NeoPixel Strip or use Flora Versions , which are available in sheets of 20.   In the case of the potentiometers, the 16 LEDs surrounding them will be implemented using NeoPixel Rings as illustrated below. Observe the small white "dots" shown in this image. These 5mm diameter dots—which look like mother-of-pearl—will be mounted flush with the brass panel. I think this is going to look incredibly sophisticated.   As it happens, there can be complications with regard to using real mother-of-pearl, but I found some amazing acrylic imitation mother-of-pearl equivalents—called Pearloid Dots—from the Stewart MacDonald company, which offers "Everything for building and repairing stringed instruments" (these dots are originally intended to be used as inlays in the frets of guitar necks). At first I was worried that the light from a NeoPixel wouldn't pass through the Pearloid Dot, so I purchased one to play with—it works perfectly and looks soooooo coooooool! All of which leads us to the part where I'm interested in hearing your thoughts. The potentiometers can be rotated through a 300 degree sweep, which means the pointer won't be able to point to three of the pixels—say the three shown in blue below:   Now, we could simply decide to not drill these three holes through the front panel, but that would we wasting three LEDs, and as far as I'm concerned you can't have too many LEDs. Also, who is to say that we might not replace these potentiometers with ones that have a larger (or smaller) sweep capability in the future? Quite apart from anything else, we can use these three LEDs as part of the self-destruct sequence should anyone be foolish enough to press the "Moderately-Sized Red Button" in the bottom panel. Even in their un-used condition, we can still light them up with some default colour (any suggestions?). Now consider the rest of the LEDs. I'm trying to decide how we should use these to reflect the current state of the potentiometer. Remember that these are individually-controllable tri-state LEDs, each of which can be assigned any colour and set to any level of brightness (from fully off to fully on). Purely for the sake of argument, let's start by assuming that we shall employ only two colours: green = good and red = not-so-good. In this case, it seems to me that we have two main choices as illustrated below:   Suppose we are considering "Overall Mood," for example. At one extreme we might have something like "Generally Cheerful"—at the other we might have "Be Afraid, Be Very Afraid" (this is illustrated on the left-hand dial). Alternatively, we could say that the centre position is the one we would prefer, with different negative options on either side (this is illustrated on the right-hand dial). The advantage of the first option is that it's conceptually and visually simple; the advantage of the second option is that it offers more conceptual and visual interest. Of course, we aren't limited to only two colours—we could go from green to yellow or orange to red—in which case the original approach of ranging from one extreme to another might be best as we have only a limited number of pixels. The next thing to consider is that we could leave all of the pixels fully on with their designated colours, and simply use the white line on the knob to indicate the current state setting; this is illustrated in the left-hand portion of the image below:   Alternatively, the default state of the red and green pixels could be set to be on, but at a lower intensity. As one rotates the knob clockwise, the pixels could be brought up to full brightness; this is illustrated in the right-hand portion of the image above. And we aren't limited to having only static (on, off, dim, bright) values—we can easily set individual LEDs to flashing (or "breathing"), for example. The bottom line is that the world is our lobster (or crustacean of your choice). We can do anything we want with these LEDs, limited only by our imaginations. Furthermore, we aren't locked into any particular scheme; we can try multiple scenarios and select the one that is the most mentally stimulating and visually appealing. The point is that "two heads are better than one," as they say. I have some ideas of my own, but I bet that you do too, and it may well be that your ideas blow mine out of the water. So what do you say? How do you think these rotary LED displays should work? Which of the above base schemes do you prefer (good-to-bad, or bad-to-good-to-bad)? Should we display just two main colours (green and red, or orange and red, or...) or multiple colours? Should we simply specify the brightness of the LEDs as static quantities, or should we have some of them flashing or breathing? Any suggestions will be very gratefully received.