Anything not specifically related to the Speeduino hardware. Eg sensors, bluetooth, displays etc
User avatar
By DeeEmm
I had another issue with a Bluetooth module today and so decided to take a deeper look into this issue. I was unable to establish comms between Tuner Studio and the Arduino via the BT module connected to Serial 1 (pins 0/1)

So I set up some tests using the Mega Pro, a UART serial adaptor and a BT module.

First I set up a test to transmit directly between BT and UART modules. I wanted to take the mega out of the equation and see if comms would work peer-to-peer. I connected the modules to each other (rx-tx / tx-rx) and used two instances of SerialTerm to send and receive data between the devices. The UART was set to 5v. Both devices sent and received data with no issues. So far, so good.

Next I did a test using the serial monitor in the Arduino IDE and the BT module connected to Serial 2 (pins 18/19). I wrote a quick sketch to passthrough the data between Serial 1 and Serial 2. Again the test was successful.

Next I wanted to test the BT module connected to Serial 1 (Pins 0/1) however these pins are also connected to the USB port so it is not possible to use both the BT module and the USB port at the same time. This in turn meant that I could not use the serial monitor in the Arduino IDE to test. So I connected the BT module to Serial 1 and connected the UART module to Serial 2 and used two instances of SerialTerm. Again I used the sketch to pass data between Serial 1 and Serial 2.

What I found was very interesting. It was possible to send data from the UART to the BT module (via the mega) but not the other way around. Commands typed into the UARTs serial terminal appeared in the BT's serial terminal, but commands typed into the BT's serial terminal did nothing / went nowhere.

To validate what I had found I swapped the connections for the UART and BT modules over and found the same thing happened to the UART module when connected to Serial 1. Commands typed into the BT's serial terminal appeared in the UARTs serial terminal but not vice versa.

This seems to point towards an issue with the TX line (Pin1), and I'm guessing is most likely related to the CH340 serial chip on the Mega Pro somehow affecting the TX line.

So next I desoldered the CH340 and then retried connecting using Tuner Studio and it connected first time. Bingo.

So I now have an idea of what is causing the issue, but not an exact cause. Nor do not have a fix at this stage as removing the CH340 chip is not really a workable solution.

Blocking diodes may work, but there is no way to implement them as the issue resides on the mega itself. I tried adding a pullup resistor to the TX line, but this did not work.

Happy for any suggestions...

User avatar
By DeeEmm
Just to add. I took a look at the Mega Pro's I have here and noted that they are visually different to others I have seen online and have used in the past. They do not have robotdyn screen printed on them but they do have robotdyn visible within the PCB traces. My guess is that they are clones and that the issue may relate to the components used. The components on the robotdyn boards are visually different.

So I've ordered a genuine robotdyn board and will do the tests again once it arrives.
By dazq
There is no "official" layout or design to a pro board. I have a few different types ( some with onboard serial/usb some not)
I had a few issues when developing my gears firmware in the beginning thanks to odd behaviour from a pro board( worked fine on a normal mega!)
User avatar
By DeeEmm
Dazq, they do indeed do two different designs, one with onboard USB and one without. The space saving for the non USB version is about 3mm. The earliest versions I recall seeing were by robotdyn which is also visible etched in the PCB traces. They have never been officially Arduino sanctioned however, just marketed as 'Arduino compatible'. I would expect that this is not an issue on the non-USB versions (see below).

I have had some further success with this and I think mostly got to the bottom of it. The TX line from the CH340 goes through a resistor before tying into the CPU, the TX pin itself goes direct to the CPU and so these two lines are effectively connected together at the CPU. Technically this is a bit of a no-no for serial comms design which should never have multiple devices on the same line. Unplugging the USB device (your PC / laptop / etc) does not remove the serial device from the line as the CH340 is still present in circuit, so doubling up on Serial 1 by breaking out the line to header pins is pretty much just a hack.

But anyhows, I digress. I upped the resistor value from R220 to 1k, this has got the board to work in a majority of cases, I suspect what is happening is that the CH340 is shunting the TX line. In those cases where it did not work I was able to establish communications by instigating a reset on the Arduino. The devices that required this to connect were all of the same type. I will post more details on those later once I've worked out what type they are.

Swapping this resistor out for a diode may also be another solution but I'm not 100% sure on the reason for the resistor. It is not required under the CH340 specs. I suspect (ironically) that it's job is to prevent the CH340 acting as a shunt to the TX/RX pins (there's one on each line).

Looking through the specs for the CH340 and comparing against the schematics of the Pro Mini it is clear that for the USB comms the reset signal is required as it is triggered by the DTR signal from the chip. This is also standard on the normal mega. Of course this is the cause of the USB reset issues that the Speeduino suffers from.

I suspect that hooking up the DTR signal from the BT devices will therefore fix this issue in all cases and is a technically correct solution. It is also similar to the hack you need to use to upload a sketch by BT where you instigate a reset. However I'm not sure how this would work in practice as a reset obviously kills the engine and establishing BT comms is not an instant thing. BT comms would therefore need to be established before starting the engine which for those running BT driven dashboards and remote devices would be a complete PITA and lets not even consider what random bluetooth connects and dropouts would do.

Of course, These issues do not manifest themselves as much on the larger Megas, which may be due to the comms chip used and a slightly different circuit design / values. It might be possible to dial this mod in a little better with different value resistors as 1K was the only value SMD resistors I had at hand, perhaps with a different value the reset might not be required?

So that's where I am. I can now get all but one particular type of BT device that I have here to reliably connect. The other type will only connect with a reset. I will justs avoid buying that type in the future.

I think the next thing for me to check is to compare the clone board I have here against the robotdyn version when it arrives and see if the issue is present on the Robotdyn board and if not what the component values are. I note that the 220ohm resistors are common to the USB input as well. Have they substituted values to reduce costs by reducing the component count? Who knows! Would be good to get a workable and repeatable solution for this as I use a lot of these.

EDIT: I note on the image below that the resistor values are also 220ohm and this appears to be a genuine robotdyn board.
Last edited by DeeEmm on Fri Jun 11, 2021 12:23 am, edited 2 times in total.
User avatar
By DeeEmm
Here's the offending resistor circled in yellow.

The one above it is the RX line
ard-mega-pro_top_zc (1).jpg
ard-mega-pro_top_zc (1).jpg (107.43 KiB) Viewed 7103 times
By hindsight
Interesting, and probably explains a very similar sounding issue that I struggled to trace beyond being something on the tx line.

What's your thoughts on a recommended solution? does the 1k resistor swap remain the best way forward?
User avatar
By DeeEmm
I need to get some more resistor values and do some further testing as I suspect that the 1k may not be optimal as I have noticed that I am getting comms drop outs.

Unfortunately the Robotdyn board I ordered arrived and turned out to be a clone so I have not been able to validate my suspicions there.
I can't believe no one brought this version before:
Untitled.png (534.36 KiB) Viewed 5978 times
It's a variant without the CH340G. I didn't know it existed until now. I ordered it and it arrived. Bluetooth connected without any problems! To program the board you just have to use an external USB-UART like PL2303. The only problem with this board is that it's not 100% pin compatibile with the CH340G version. This one is shorter by 3 mm and one pair of pins. VIN falls into GND place and 5V goes to GND. One option is to redo the board you plug this into, the other is not to solder the first 3 pairs of pins: VIN, GND, VCC and connect them on top using additional wires. Then all other pins remain compatibile.
IMG_20211016_120754.jpg (5.77 MiB) Viewed 5978 times
IMG_20211016_120837.jpg (5.24 MiB) Viewed 5978 times
IMG_20211016_120902.jpg (466.55 KiB) Viewed 5978 times
By hindsight
DeeEmm wrote: Fri Jun 11, 2021 12:01 am EDIT: I note on the image below that the resistor values are also 220ohm and this appears to be a genuine robotdyn board.
The resistor in the image quoted, and on my boards are marked "220", which are not 220ohm, but 22ohm. I've just swapped both of the 220 (22Ohm) resistors to 2200 (220Ohm), as per a thread elsewhere on this forum, and bluetooth is working for me.
Fuel Pump for a 150cc

I just picked one off amazon with the lowest fuel […]

Honda's Alternator Control is just a PWM based o[…]

Anyone with ESP32C3?

Haven't tried that myself, but as I have used a zi[…]

For Peugeot Valeo throttle valve to fix throttle[…]

Still can't find what you're looking for?