Hi guys,
I cannot get my ProMicro to accept provided serial data on its serial port D0, which supposed to be the UART, Right?
Can it be the ProMicro cannot process this baudrate??
I had a readout on the serial monitor with corrupt data and I found out I had to invert the signal.
But now I cannot receive anything.
(I used a transistor with a pullup of 4k7 on its collector. The data is provided to the base of the transistor, through a 10K resistor. The emitor is grounded.)
Any tips on that?
115200 should work. I did use it on Leonardos (same processor) with no problem.
Original Pro Micro or clone? If the latter, verify that the crystal indeed matches with what you bought (8MHz vs 16MHz).
You probably know this but D0 is Serial1 on the Pro Micro.
You can run a loopback test by shorting D0/D1 to test the processor's hardware.
Read data from PC (Serial), send to Serial1, read back from Serial1 and send to PC.
Why are you using a transistor?
Keep in mind that is UART1 and should be referenced in the code as Serial1
It could be that the output of the transistor circuit is not a nice rectangular waveform; it could have slow rise and fall times together with rounded edges.
You can reduce the rise time of the signal by reducing the value of the 4k7 resistor.
Do you have an oscilloscope that you can use to view the waveform?
What kind of transistor ?
The pro micro can easily process serial data at 115200 baud.
Where does this data come from? What is the output level of the sender? Maybe you need a RS232<->TTL converter?
Hi Guys,
I was out on some other issues but back on track again.
I have data that is supposedly low with high pulses. And needs to get high, with low pulses.
I get the data from the (I was told it is called the "HAN port" in English), dataport from my KWh meter. (it is called "P1" meter in Dutch).
It has a fixed 115200 Baudrate and because I did not get a good readout, I thought it might have been because the speed is to high.
Originaly I got the data straight from the HAN port and I had my PCB created in that manner.
So when I was told the signal needed to be inverted, I re-arranged the resistors a bit and placed a transistor.
This was the original PCB setup
And this was the one after inverting:
(My appologies in advance for the poor adjustments, But I guess you catch my drift)
Your board says RS-485. Have you ever confirmed that it is RS-485? If it really is, there is NO ground reference for the data and to invert you just swap the A and B wires.
Please do not pay attention to what the board says.
That is the part which has nothing to do with the communication of the HAM data.
The RS485 is only there to parse the (by the ProMicro slave) collected data to my Arduino Master.
I use the serial monitor to check weather there is data retrieved from the HAM and if it is workable.
So far I only get gibberish. Inverted and uninverted. ;-)
the S9018 H331.
It was the only one I had laying around.
I checked the type and because I only use it for switching saturating it completely, I did not see harm in using it.
I do however, purged a few BC547's.
I like to rule other things out before testing the device with this new transistor.
It it quite a bit of work but if necessary I will of course comply.
Thing is... Both transistors are equally suitable for ordinary switching purposes.
Yeah i guess. 115200 is anyway not a very high speed and it should suffice.
If the board doesn't provide visual confirmation, a simple blink test to confirm that the clock speed is correct will probably do.
As stated before, NO ! the micro can handle up to 1Mbps, so 11520bps is a breeze.
You have still not shown us any code, and to rule out anything silly like using swSerial, it would help if you do show us.
Are we talking about this smart meter interface?
Then it seems to be an opencollector output, that needs a pull up resistor at the receiver side.
But also inverted as a result of the opto-coupler.
That does explain why the circuit isn't working.
The 10K resistor on data input should be a pullup to 5v,
and the data input can connect to the transistor directly.
When the opto-coupler pulls it LOW, the data output should go HIGH
OK, to get this right... I think I know where I wend wrong.
The HAM its Optocoupler pulls the base of the transistor down.
If it doesn't the 10K resistor will pull it high.
This is then inverted by the collector side of the transistor.
If I understand it correctly, the HAM pulled the current to ground, creating a kind of GND on the Base side. When the HAM's optocoupler did not pull it down, there was a floating voltage on the base, right?
I think I get it now.
I'll kickstart the solderiron and get to it!
Guys, thanks for the effort all together.
The 10K pullup resistor between the VCC and the base did the job!
The scematic of my last post was correct.
Now the next phase, getting it to talk to the master by using the MAX485.
I'll manage!
You already have a TTL signal that can go straight to an Arduino serial connection. Are you going to convert this TTL signal to RS-485 and on the other end, back to TTL again? How far does the signal have to go?
Yep !
That is the question, maybe just a few centimeters.
Time for some more elaboration. 
The data is stored on the ProMicro temporary.
The Master (Arduino Mega, about 15-20 meters away) is connected by UTP cable.
The ProMicro has the 120R termination resistor on the MAX485 device.
Past the Mega is yet another Arduino, an Uno. This is also a slave, terminated on the MAX485.
This communication is already tested. Well... Not all three together, but nevertheless.
The Mega controls a few relaiscards, steering valves.
The Mega is also connected to about 8 DS18N20 temperature sensors, which are placed on several places on the heatingpipes.
Based on the temperatures (Which are "created" by heatpipes, a wood stove and by the central heating) the valves are steered to increase the temparature in a buffer tank, or to use that heat when needed. (All in a nutshell. There is more to it)
The Arduino Uno is on placed near the buffer tank to also steer a valve or two.
It also can turn on or off a pump to circulate the heated water into the tank (when heated by the stove) or to pump it back into the system where it gets involved into the normal heating system.
The uno also determines, based on -again- a few temperature sensors, the heat on several points. In example, the Hychiene Spiral, which is fed with cold water, provides warm water. If te temperature is below 70C, it is passed to the boiler to extra heat it. If it is over that point, another valve passes it to a bypass so it doesn't get to be post-heated to reach common "warm water temperatures".
All of that is tested.
But to get it combined I let the 3 arduino's talk.
And now the reason for this HAM readout option...
The Buffer tank can also get heated electricaly. I have a 500/1000/2000 heater installed which get powered by my PV solar panels.
If the solar panels generate more power than consumed, it floods back to the grid. There comes a point we have to pay for that.
So by buffering the heat, generated by the solar panels, I can store that heat for warm water purposes. So I save on my gas bill.
By monitoring the amount of energy I deliver to the grid, my UNO can switch a combination of those heating elements, which are submerged into the buffer.
In orders of 500Watt, I can take 8 steps from 0 to 3500Watt.
If another device is turned on and my internal consumption increases, it will be noticed by the ProMicro and (on demand) parced to the Mega, which in turn tells the UNO to switchs its ports accordingly.
So that is the bigger picture, again, in a nutshell.
It combines my interests in Electronics, Arduino and Programming, with my drive to innovate our home to be self sustainable. 
