Boomer48

Thanks Bob. Mostly I do this stuff to pass the time during the winter months and to sometimes entertain the grandkids. I used to do strictly PIC microcontroller projects in assembly language but most people prefer Arduino projects.

Thanks. It was just a fun little tongue-in-cheek project specifically for Pi Day. My earlier hobby projects mostly used small PIC micros so after I started playing around with Arduinos I knew I needed to just get down to the bare Atmel chips for my battery operated builds.

I have no idea what your "sender" is doing. You should build the RF Decoder I mentioned to verify it. One thing I saw in your receiver code that is different from mine is this:#define One_Bit_Time 200 // nominal = 188#define Zero_Bit_Time 600 // nominal = 564My code has 120 and 500 for the bit times.

It could be any number of things like sync or bit time mismatch or just the wrong codes. I suggest that you look at my Instructable "Arduino RF Sensor Decoder". That would help you see what your transmitter is sending and then you could make sure that the code in the ATtiny85 receiver is properly set.

As I explained in the Instructable the LM298N module does not work properly at the higher switching rates.

So glad to hear that you figured it out. I usually lean the most on the projects where I have the most problems. I always want to figure things out at a low level so I tend to avoid the standard libraries.

Glad to hear it works with an Arduino. The "more zeros" comment was based on some online chatter when I was researching the issue. The sequence in my software matches what the spec says and it apparently works with your Arduino so that shouldn't factor into your other MCU issue. I don't think there is any response following the "wake-up". If you get responses to the subsequent commands then it's awake. If not, then a few more zeros may or may not help. The normal sequence worked for both my Arduino and my PIC applications.Connecting the MCU RX and TX lines is a good basic test that the right codes are being transmitted but it doesn't tell you if the baud, parity, start and stop bits are properly set for the RFID board or if the wiring is correct.

Sorry to hear you are having so much trouble. It sure sounds like a basic UART communication issue. If you had access to an Arduino Nano or UNO you could at least verify that your boards are OK. The PN532 should be easier to work with. If your board is like mine, it has a DIP switch for setting the communications mode and both sections should be open for HSU. I actually just took the switch completely off of the board. Also, the baud rate should be set to 115k and I'm assuming that you are sending the wakeup sequence.

If it is accepting the write commands properly you should only get a single byte response that echos the register number. So the 15h 40h command should only return 15h. Sounds like the RC522 UART is not working for some reason. If it were me I would try the following: 1. Double check the board modification with an ohmmeter to make sure the right traces are disconnected and the one that needs to stay connected is connected.2. Disconnect the RC522 and see if you get the same response. That would likely mean that your micro RX buffer is somehow echoing the TX buffer. Make sure the baud rate is 9600, 8-bit, no parity, 1 stop bit.3. With the RC522 connected, make sure you have 100ms or so delay before sending the first command to it. I have that in my software specifically for the LCD…

If it is accepting the write commands properly you should only get a single byte response that echos the register number. So the 15h 40h command should only return 15h. Sounds like the RC522 UART is not working for some reason. If it were me I would try the following: 1. Double check the board modification with an ohmmeter to make sure the right traces are disconnected and the one that needs to stay connected is connected.2. Disconnect the RC522 and see if you get the same response. That would likely mean that your micro RX buffer is somehow echoing the TX buffer. Make sure the baud rate is 9600, 8-bit, no parity, 1 stop bit.3. With the RC522 connected, make sure you have 100ms or so delay before sending the first command to it. I have that in my software specifically for the LCD but it also allows the RC522 time to initialize.4. Try removing the dummy read (80h) command.

Are you displaying the results on an LCD or looking at them some other way? Do you get any response from the "Dummy Command"? Maybe try not sending the "Dummy Command". If you send B7 and get B7 it is acting like it thinks that is a write command which doesn't make sense. Maybe try displaying the return values for each write command you send during startup to make sure that they return the correct register number. I did mention that another user had a problem with his brand of module not doing the UART communications after the board mod. Maybe that is the issue. If you want to use Instructables mail to send a plain text version of your software I can take a look to see if I spot anything obvious.

Changing the frequency is obvious in the IDE but knowing that you need to do "Burn Bootloader" is not. That part is what I mention.

I'm not familiar with the LPC1769. Are you using C as your programming language? If so, look at my Arduino version Instructable. It kind of looks like you are getting the Dummy Byte as your return. If you send just the Dummy Byte you should get either 0x00 as a return or nothing. There was an earlier commenter who had a problem with the particular module he bought. Read that exchange to see if yours might me the same type.

Sorry, I don't do stuff like that. I'm strictly a hobbyist.

I don't know of such a device. The internet part of this project was just a "can I do it" exercise. The simple solution is to buy the Etekcity Voltson Smart Outlet or one of its many competitors. That's what I use and it's compatible with Amazon Alexa.

Thought this might be a more universal decoder than my own project but it gave completely wrong codes for my simple NEC remotes. Guess I'll have to dig into the library to see what it's doing.

This is from the Arduino Reference: "This function works very accurately in the range 3 microseconds and up. We cannot assure that delayMicroseconds will perform precisely for smaller delay-times."That is based on the 16-MHz clock of the Uno. Multiply that by 16 for the 1-MHz ATtiny85 and you get 48usec as the bottom limit for accuracy.

That value also includes time for the second read of "micros". I haven't looked at the code for the those functions to see how many assembly language steps they take. I did a lot of hobby projects on the PIC before "discovering" the Arduino. All of my PIC projects are written in assembly language so it made me very aware of software execution times based on clock speed.

I've done a lot of bit-banging serial stuff but not much "normal" I2C. Most of the bit-banging was on my PIC micro-controller assembly language hobby projects. I just remember seeing somewhere that I needed to right shift the stated I2C address to get the actual value to use in the software. That was a stumbling block for awhile when I was first trying to do I2C on the PIC.

I'm assuming that you are using C/C++ in code composer studio. Here is a link to an Arduino version of I2C interface code for the PN532:https://github.com/adafruit/Adafruit-PN532They show the I2C address as 0x48 (like you say) but it gets right shifted one bit for transmission (#define PN532_I2C_ADDRESS (0x48 >> 1)). Maybe that is your issue. Good luck.

I found the PN532 to be easier to work with and it automatically returns the UID as a response to the SCAN command.

If you want to make an RF receiver that doesn't need an Arduino, take a look at my Instructable "Virtual Hide-and-Seek Game". The board I use there will decode up to four codes from the same transmitter.

Yes, I misspoke about using the Nano. The interrupts registers have different labels in the Nano and ATtiny85. My Instructable "Arduino RF Sensor Decoder" shows the correct labels for the Nano. Replace the GIMSK and PCMSK lines with:// Enable INT0 external interrupt, trigger on both edges bitSet(EICRA, ISC00); bitSet(EIMSK, INT0);Then change the interrupt handler name to: // INT0 interrupt handlerISR (INT0_vect)The INT0 pin on the Nano is D2 and cannot be changed. I've used the pin change interrupts on the Nano but it is a bit trickier than just using INT0 if you don't use the Interrupts library for the Arduino. Hope this works for you.

I didn't use a Nano for the receiver but you could if you want. Just input the signal from the RXB6 board to D1 or change the input pin in the software. I'm not sure what you want to do with the rotary encoder. The push button switch could be used in place of one of the switches shown in the schematic but the rotary output cannot be used in this project.

Thanks for the question. The metal piece goes inside the PVC, then the battery sits on top of it. The best way to put it together is to put the battery inside the PVC with the + side up, set the metal part on top of the battery, then slide the flashlight case over the top of the PVC. Turn it over and screw on the end cap.

Thanks for the comment. Any difference in brightness is not really noticeable. As for adding a recharging board, I do that in my portable projects but there is no room for the board in these small flashlights. I have a few spare batteries so it's easy to just swap them out as needed and recharge them offline.

I cannot tell if it would work because I do not know your system. It would be difficult to build a replacement that would exactly match your PICAXE software. When I do an internet search I see ACM120 modules for sale from other vendors. I also see other RFID read/write modules available. I assume from your comment about the MAX232 that you need one with an RS-232 interface. It looks like some of those are available even though most now use USB. Good luck.

I went ahead and translated my PIC assembly code for the cheap rotary switch to Arduino and it acts pretty much the same way. When you enter the interrupt handler for the clock, just do an if/else check on the data line. One key is that I use the 10k pull-up resistors provided on most rotary switch modules and I add 0.01uf capacitors to ground on the switch, clock, and data pins. That's a standard technique for eliminating debounce on the encoder lines.

I looked at the PIC micro code I wrote four years ago (in assembly language) for reading a rotary switch and saw that I had used the single External Interrupt pin for the encoder clock line. Once I was in the interrupt handler I simply read the high/low value of the encoder data line to determine the direction of movement. The ATMega328 has two external interrupts so you could use one for the encoder and one for the switch instead of needing to finesse a pin change input. Just a thought. I plan to do an Arduino project that will include a rotary switch so that's how I ended up here to begin with. I like figuring out stuff myself but I'm always interested in how other people attacked the problem.

I haven't looked at your code but thought I would provide a couple of general pointers from my experience. First, switch debouncing may require more than 10ms. I typically use 50ms just to be sure. Second, whenever I want to use a single switch to get in/out of a function or to step through a function I do one of two things. To get in/out, I generally use an input pin tied to an interrupt handler. Just add a flag variable and toggle the flag each time the interrupt is handled. Then check the flag status in your "openMenu" function to determine if you are entering or exiting.If I want to step through a function (like setting hours, then minutes of a clock) I detect the difference between long and short switch presses. For example, short presses to increment the hours, then…

I haven't looked at your code but thought I would provide a couple of general pointers from my experience. First, switch debouncing may require more than 10ms. I typically use 50ms just to be sure. Second, whenever I want to use a single switch to get in/out of a function or to step through a function I do one of two things. To get in/out, I generally use an input pin tied to an interrupt handler. Just add a flag variable and toggle the flag each time the interrupt is handled. Then check the flag status in your "openMenu" function to determine if you are entering or exiting.If I want to step through a function (like setting hours, then minutes of a clock) I detect the difference between long and short switch presses. For example, short presses to increment the hours, then a long press (typically one second) to move to the minutes setting. Hope this helps.

I haven't looked at your code but thought I would provide a couple of general pointers from my experience. First, switch debouncing may require more than 10ms. I typically use 50ms just to be sure. Second, whenever I want to use a single switch to get in/out of a function or to step through a function I do one of two things. To get in/out, I generally use an input pin tied to an interrupt handler. Just add a flag variable and toggle the flag each time the interrupt is handled. Then check the flag status in your "openMenu" function to determine if you are entering or exiting.If I want to step through a function (like setting hours, then minutes of a clock) I detect the difference between long and short switch presses. For example, short presses to increment the hours, then…

I haven't looked at your code but thought I would provide a couple of general pointers from my experience. First, switch debouncing may require more than 10ms. I typically use 50ms just to be sure. Second, whenever I want to use a single switch to get in/out of a function or to step through a function I do one of two things. To get in/out, I generally use an input pin tied to an interrupt handler. Just add a flag variable and toggle the flag each time the interrupt is handled. Then check the flag status in your "openMenu" function to determine if you are entering or exiting.If I want to step through a function (like setting hours, then minutes of a clock) I detect the difference between long and short switch presses. For example, short presses to increment the hours, then a long press (typically one second) to move to the minutes setting. Hope this helps.

Thanks. I modified this to test out my 32x32 panel with an Arduino Nano.

Sorry for the late response. I never saw a notification that I had a comment. Nothing special for the wiring. Hope the pictures help. After soldering I added some clear glue (like GOOP brand) to the RF transmitter module and to the front switches board to make them sturdy.

If you grounded the EA pin and it still comes up in SPI mode then either the chip is defective or the clone doesn't read the configuration pins at power-up. Given that all of those boards are built for SPI mode they might have just cut corners on the chip design.

The original one I got doesn't have any markings on the chip. The most recent ones I bought (February) are marked "MXP RC522" so they must be clones. Here is the eBay link for my most recent purchase: https://www.ebay.com/itm/5PCS-RC522-Card-Read-Ante...All of them look like the board in my Instructable (except for the chip marking) and do not have the HW-126 you mentioned.

Does your non-working board look like the board in the picture above? I've purchased several of these and they all look the same so I'm not sure if someone is cloning the chips or not. there are other versions of modules that use this chip so they may be wired differently. If it looks the same try to see if there is any voltage at all on the EA pin. If it is a clone chip that pin may have something inside that is holding that pin at something other than zero volts. The only other alternative would be to try to solder a wire to EA and ground or touch EA with something like a grounded needle during power-up. It's supposed to read that pin at power-up so a temporary ground might tell you if it actually can go into UART mode. Good luck.

Yes, Miguel is the expert on these boards. I checked the link you provided and it looks like the Firmware Version is different on some of the clone boards (0x12 or 0x15 were mentioned). My boards are 0x92 (per the chip spec) and that's what my software looks for. Try one of the others mentioned in the link or just comment out the call to FW_Version in the Startup so it won't fail. Another thing I saw was someone mentioned communicating at 115k baud instead of 9600. Maybe try some other baud rates to see if anything pops up.

I just got three of these boards from a Chinese seller and two of them have the Uno bootloader like you state in your Instructable but one has the LilyPad bootloader. The only difference in the boards is that the "genuine" one says "LilyPad Arduino" instead of just "LilyPad". Also, some of the FTDI converters have the pins reversed so always look for "GND" (ground) to know which order to connect them.

You can just solder a standard ceramic capacitor to the unpopulated solder pads shown in the top right of the board picture. I use a 22pf capacitor but a 47pf also works. I had to do this in order to get the module to work properly below 4.75 volts.