Recent Posts

Pages: [1] 2 3 ... 10
Any other recommendation?
Walk before you run? You might find the following background notes useful

Displays / Re: Help me select - LCD - TFT...
Last post by Nick_Pyner - Today at 04:51 am
Am I correct that only OLED displays have a dark black background?
Definitely not. You can use a graphics LCD and make the background black, or any other colour, and having individual characters 0.96" high, or more,  should be quite easy as well.
Project Guidance / Re: 28BYJ-48 Stepper motor con...
Last post by paulwece - Today at 04:50 am
The transistors are NPN, and the collector of the Darllington pair approximates a switch to "ground", sinking motor current. Schematic below.

Oops, I meant NPN.

I'm still a bit confused with that COM pin (9) of the ULN2003 and all those flyback diodes connected to it. I understand it's because of the inductive load. You connect the power supply to the COM, so the flyback diode will be reverse biased when there is current at the collector, but as you make the switch, the flyback diode will be forward biased and since the COM is connected to the power source (same as the motor), it will essentially form a loop through the motor to dissipate the the energy?

Project Guidance / Re: Serial communication using...
Last post by VJ_Sharma - Today at 04:47 am
1. I wish to communicate between arduino and PC
2. I dont care what  my arduino prints. I just want it to receive a string from the serial monitor and send a string to the serial monitor  without using the USB cable using the pins instead.
   thats all I wish to  do. Send and receive data between PC and arduino uno using Rx and Tx pins using a USB to TTL converter.

As of now I can send from Uno  but i cant receive data and take decissions according to string recieved

3. I am not using pins 0 and 1 for anything else.  plus I am able to print "Hello world" as in the first code i submitted so i don't think software serial would solve my problem but I will try it never the less
The ground is also common for arduino and TTL converter

I am open to any other suggestions or querries just help me get it working please!
Hi guys..

Was having some similar issues over the last couple of days.

Decided it was time for a full audit of my main win 7 box.
I have a profile for the wife on here too btw and that's IMPORTANT here.

I did all the usual stuff but was still getting unacceptable compile times.

Did the usual clean ups on my profile CCLEANER and WISE reg cleaner and nothing changed.
Logged into the wife's profile expecting to see it was already clean from the process on my profile.
Was I ever wrong...So cleaned up her profile too and dropped back to mine...
A little better but still not quite there.

Decided I needed to go deeper and seeing as I am pretty careful I went straight to the wife's profile again.
Ran ESET online scanner which found a heap of things (over 90) nothing too nasty and mainly PUP's but items that were not supposed to be there.
Nailed em all and did a reboot.

Even the boot time was improved.
Did the same scan for my profile and although it found a couple of items I knew what they were and was able to safely ignore them and nail a couple more that had somehow MIGRATED from the wife's profile.

Re did CCLEANER and WISE on both profiles which found remnants from the major ESET run.
One more re-boot and BOOM everything is up to speed and it feels like a new computer.

1.6.5 is about 12 seconds
1.8.1 is about 10 seconds
1.8.2 is about 8-9 seconds
CREATE is off the chart... just don't blink !

Microcontrollers / Re: ATMEGA328PB printing all b...
Last post by liudr - Today at 04:47 am
FTDI? ATMEGA? They all have proper amount of solder. There is no short circuit.
I'm on my way out soon so I can't look too carefully but have a think along these lines:

  • Use the state change example which iirc uses modulo to determine every 4th press. Change that to 2 so you have every 2nd one. Then use if/else or to do the whole blink thing (both the dash and tail) when it's even amd nothing when it's odd.
  • Then inside the one where it's all on and you want the tail ones to go off, put the tail part inside a while (!digitalRead()) so when the brake light line* is high it's ignored,

*Don't forget to condition the 12V down to 5V if you didn't already else you'll let the magic smoke out.


Thanks so much for taking the time to respond.

I also cannot get an Arduino Uno to recognize the I2C address when I run the scanner program.  I have been powering the sensor with an external power supply for all of these tests.  Usually around 9 volts because that seems to be the number where people don't have any problems.

The sensors also have a DVCC pin (which I mentioned earlier) that is meant to be separate from the sensor power and is only associated with the logic of the I2C side of things... this is the only pin that I was powering by the Wemos in one test (and an Arduino in another test.) 

I have tested 3 situations, all of which I supplied 9V to the sensor with an external power supply and had a common ground between everything.

1. providing 5V to DVCC via an Arduino
2. providing 3.3V to DVCC via an Arduino
3. providing 3.3V to DVCC via a WEMOS (ESP8266)

None of the scans found an I2C address.

As a side note, the sensor works fantastic if not using I2C, and instead, using a custom library/code found HERE or another example seen below...

Code: [Select]
#include "kSeries.h"

// Create K30 instance on pin 6 & 7
kSeries K_30(6,7);

void setup()

void loop()
  // Get CO2 value from sensor
  double co2 = K_30.getCO2('p');

  // Print the value on Serial
  Serial.print("Co2 ppm = ");

  // Wait 2 seconds

The problem, however, is that I can't get this code to compile on the WEMOS, only on the Arduino.  I'm wondering if it has anything to do with SoftwareSerial not working the same on the ESP8266?

My project requires the ability to transmit this data wirelessly, therefore my workaround was going to be to have the Arduino take the measurements with the code that works, and then transfer those measurements via I2C to the WEMOS and let the WEMOS then throw this measurement over the airwaves.  It's ridiculously tedious when the WEMOS itself should simply be able to read the value via I2C directly from the sensor and do all these things.

Once again, any help is greatly appreciated.  I have to imagine someone has gotten this beauty up and running on I2C.

Thanks once again for looking into this as I'm crashing and burning fast right now...

When I used the example modbus slave project with the <ModbusRtu.h> include project my external RTU can read holding registers from my Arduino fine. When I use the identical code and the identical shield containing the RS485-TTL converter on the Mega2560 I get no response when polled from the RTU.

The reason that I used two UNO boards was simply to overcome the interrupt conflict between the two libraries. If I was much smarter I would use the pin change commands and write dedicated code for my project but I simply don't have the familiarity with the platform.

I have tested both <ModbusRtu.h> and <wiegand.h> include projects and they both work great separately. But to combine them on one UNO board is beyond my programming knowledge. So by setting up a I2C connection between two UNO's I was able to deliver a solution.

An application using both include projucts gives compile errors because there are limited pin change interrupt resources on the UNO. Does that explain my problem a bit better?
It  looks like you have the input pin floating when the button is not pressed.
My thought too, but I wonder if OP means the below literally, ie in a pattern as distinct from random:

if i dont press then i can see it is printing 010101010101
Pages: [1] 2 3 ... 10

Please enter a valid email to subscribe

Confirm your email address

We need to confirm your email address.
To complete the subscription, please click the link in the email we just sent you.

Thank you for subscribing!

via Egeo 16
Torino, 10131