hi, This is a simple circuit for converting a 4mA thru 20mA Loop signal to 0V thru +5V, suitable for an ADC input. When using a LM358 OPA, the closest specified lowest swing is approx 20mV above 0V. Take care when using with a ADC that will not accept excessive outputs voltages from theLM358. For example with a PIC if the OPA output could exceed 5V in operation, using a limiting resistor, that will limit the ADC input current to less than ~10mA. The internal clamp diodes of the PIC are rated at ~20mA max. A series 470R connected between the LM358 output and the ADC input pin will limit the clamp current to ~10mA, if the OPA output reached +10V. NOTE: 16 May2012 Added a 0V to +10Vout version of the converter NOTE: 17 May2012 Added a 0V to +5/10Vout version of the converter for a 0mA to 20mA input.
Hello and Welcolme to Cocodrilabs! Previously known as Engallamientos, Cocodrilo Laboratories is not only my hobby: it’s also my favorite way to learn and share knowledge since 2007. The topics are Electronic projects, Home and Machine Improvement, and DIY Repairs. My posts have variable technical complexity and some of them have been made with the guidance of members of the Electro Tech forum over the course of years (see below). As I state on the site, unfortunately I’m not an engineer and English is not my first language, so excuse me if you find any mistake before I do. I work hard to deliver the most technically accurate and honest ”step-by-step” guides. Thank you by your time, and Enjoy Cocodrilabs! cocodrilabs.wordpress.com The following posts were made with the help of Electro Tech forum members. Thank you very much by your help. Easy Bench Power Supply Installing an ...
Inkjet printers work great for making transparencies used in photoresist methods for PCB's. Unfortunately, I made transparencies less frequently than needed to keep my inkjet cartridges from drying out and decided to develop a method that would work as well with my laser printer. My printer is an HPLaserJet 4101mfp. It cannot be adjusted to make dense transparencies. The method I developed uses a black dry erase marker to make the image on the transparency more opaque. It does not smudge any of the lines or other details. It simply fills in the grain on the transparency. Dry erase markers are most commonly used on white boards when making an oral presentation . That is, they substitute for chalk used on black boards. I use Expo brand. I have not tried other brands. Expo was the cheapest at my office supply store. Permanent markers will not work. The procedure is simple. Just paint over the entire laser transparency on the toner side, let it dry, and wipe off with ...
I2C Monitor– Implementation and Limitations The implementation is shown on the next figure. For the quick prototype, the FTDI interface was replaced with the FTDI TTL cable. The implementation worked as expected with two caveats; the maximum bus supported speed is 100kHz, and if the internal buffer on the MCU overflows there is currently no indication for this. I was hoping to be able to operate up to 400kHz, but it’s not happening. Since this is good enough for what I targeted originally, it will suffice until next time. It looks like this is better suited for an FPGA application – live and learn I guess. Code is written in Oshonsoft Basic. i2c monitor.png Code Code : 'Author: languer (©2012) 'Pin Allocation: 'PIN# Main_Fn Secondary_Fn 'RA0 -> not used 'RA1 -> not used 'RA2 -> not used 'RA3 -> not used 'RA4 -> not used 'RA5 -> ...
'Author: languer (©2012) 'Pin Allocation: 'PIN# Main_Fn Secondary_Fn 'RA0 -> not used 'RA1 -> not used 'RA2 -> not used 'RA3 -> not used 'RA4 -> not used 'RA5 ->
I2C Monitor – Concept I came across an issue where some I2C communications between an FPGA and an EEPROM was giving troubles. The FPGA acted as controller between the software and the rest of the hardware; so there were two components to the issue: (1) software communications to the FPGA, and (2) I2C communications between the FPGA and EEPROM. I’m simplifying here of course, but that pretty much summarizes the issue. This I2C EEPROM was accessed every time the hardware power-up, and all its content was “read” by the FPGA (and passed on to the software). As luck would have it, every now and then something would be dropped on the communications. To isolate it a Logic Analyzer was used (and a lot of time). During all that I though; men it would be great if I had a monitor for the I2C communications, and one that can log for that matter. It probably wouldn’t have helped much in this case – but there were some other issues that were associated with this, which having such a tool ...
I’ve been looking at a simple way I can “play” and “monitor” several gadgets on my router/printer/etc room through any pc on the house. I looked at using wireless modules of different frequencies/technologies (ISM/433MHz, Zigbee, …); all would require specific hardware at each of the PCs … not quite what I had in mind. Around came two things which seemed to be “better”: The Wifly module from Roving Networks (e.g. Wifi Garage Door Opener) and the WIZ110SR module Wiznet. The Wifly module looked pretty cool, and the garage door application example I looked through was nothing short of cool. However although I am quite capable with hardware, I am not quite savvy with Ethernet stuff (you know protocols, etc). So when I looked at the WIZ110SR and saw that I could do simple RS232-to-Ethernet (telnet) communication with it I figure I could possibly start with that. So I order one along with a +5VDC wall-wart. Here’s how it went… Remember I mentioned I’m no expert ...
I’ve decided to add a timeout to both the bidirectional routine and the unidirectional routine; and then wrap this up. This project originated from a need to control two SPI devices from ADI. The single unidirectional controller presented before was based on that. The bidirectional controller was based on a need to control a proprietary SPI interface; this sort of died away, so no good reason to keep pushing it. The interface work for this is done and tested; but I have no real use at the moment. The unidirectional controller on the other hand, I have plenty of use for. Let’s do a brief flow diagram a few of the things we did previously using Oshonsoft Basic just for the sake of sanity. > Open UART for 19,200bps – there is no particular reason for this speed; but you certainly wouldn’t want it to make it slower (faster is better ). > Initialize signals to inputs and outputs – set outputs to desired states. > Set ...
After a bit more playing with this I have something that kind of works for bidirectional communications. Here it should be obvious why we are using the CTS line to tell the PC when the MCU is ready for the next command/request. For the unidirectional SPI controller we used the CTS as well, but we could’ve use a special character (or sequence of characters) on the received RS232 to let the PC know it was ready. For the bidirectional case, that is not true. Since we may be expecting a reply back from the PC, we must have a robust mechanism to tell the PC it is ready for more data – thus the use of the CTS line. So what are the restrictions? • First, the PC side must use the CTS handshaking. • Second, it cannot revive more than 255 bytes at once. Why you may ask? We defined the receive data as a byte – bytes only reach 255. • Third, 'PACKET_LEN should always be 'SPI_TX_PACKET_LEN + 3. This is so because the Packet includes the SPI_MODE, SPI_TX_PACKET_LEN, ...
Someone asked me via PM, why would I use a unidirectional (i.e. one-way) SPI interface? It turns out that in my use of SPI interfaces, most of the devices I’ve had to interface with fall in this category. The times I’ve required a bidirectional interface are not as many; and most (not all) happen to be more complex applications. I am including a couple of more applications where a unidirectional SPI interface is useful. Once the interface circuit is available, writing a UI interface is pretty simple and can help debugging. Below is a UI to control the AD9834 DDS from Analog Devices. This is a very nice little IC with quite a simple interface. In the example below, using a 20MHz clock source (for my application it happened to be a TCXO – but that’s not relevant for this), the DDS can be used to synthesize anything from 0Hz to 10MHz with a really nifty resolution. One can even switch between frequencies, control the phase of the signal, sweep from one frequency from another, etc. ...
This second part is more of a let’s play with this a little, than actually something truly new. How can we put the SPI controller to use. This may not be the best application, but we’ll this circuit to control the same NS73M FM module described previously (http://www.electro-tech-online.com/b...ansmitter.html). The use is quite simple: connect to the SPI Controller, send RS232 commands to perform the same initialization and control of the NS73M module as was done with the PIC on the other post. So what is really accomplished with this? Nothing really. But if you want to perform a quick evaluation of SPI modules, this does provide the opportunity. I also used the opportunity to create a RealStudio (http://www.realsoftware.com/realstudio/) application just because I wanted to do a nifty interface; but this could have been easily done with a simple RS232 terminal. A few caveats: • The NS73M module requires a 4-bit address and ...
Recent Comments