Modification of 4-20mA two-wire passive digital display meter Part 11 (Process summary)
[Copy link]
From the beginning of the project to the first half of the project, I always thought that the focus of the project was on the power supply processing and communication method selection of the modified circuit. If these two verifications were passed, the project would be completed. The prerequisites and necessary conditions are all met: the original computer host setting software is available; the target instrument is available normally; the RSL10 module hardware is ready-made, the routines are ready-made, and the development tools are complete; the power consumption of RSL10 itself is also satisfied: " Supply Voltage Range: 1.1 3.3 V ; Peak Rx Current = 3.0 mA (3 V VBAT) ", and the overall prediction should be able to achieve the goal. In fact, before the PCB was put into production, I had used related components to build a scaffolding and welded to do a simulation circuit test: using 5 silicon diodes in series to make a voltage drop to take power to the RSL10 module, and using an optocoupler for isolation to send data to the computer, there was no problem. After the board was made, I couldn't wait to let RSL10 send data to the instrument through the homemade optocoupler isolation board according to the data intercepted from the original PC software serial port of the instrument, but there was no response. The progress of the project was brought back to square one step by step: I suspected the optocoupler problem, the unstable power supply of the bus power supply, the distortion of the data waveform after isolation, etc. I tried various ways to deal with them one by one, but it didn't work. I remembered what Hua Luogeng said, "Be good at retreating, retreat enough, retreat to the most original place without losing the importance" - let's do the experiment again step by step, so there were later posts on doing basic experiments, isolating the data level, isolating the data byte, and even letting the MEGA88 microcontroller used for simulation receive the "original" intercepted data sent by isolation to determine whether there is an error, no problem! I was confused about the transmission protocol, not knowing whether it was a software or hardware problem. During the process, there were some "weird" phenomena that I had never encountered before: the computer simulation serial port also failed, sometimes it did not receive data, and sometimes it did not work even though the baud rate was clearly set. After setting it to any receiving baud rate, the data sent could be received and displayed correctly. I still don't understand what went wrong; later I simply changed a computer to do the experiment to avoid this big pit! After changing the computer, the serial port was "trusted", and I did another experiment: let the computer use the original host computer software to send data to change the instrument settings, which was normal, but using other serial port software to send the same intercepted data did not work, no response! The baud rate is the same, and two serial port host computer software are opened at the same time, one receives data, and the other exchanges the test by sending the same data from the original host computer and other software. As a result, the received data is indeed exactly the same! Without making a circuit, sending legal data from the computer using other software does not work, and I am stuck. In the depression, I even respect the effect of the original instrument designer's use of anti-piracy technology! Such specific and unproblematic problems really exist. I thought about it day and night but couldn't figure it out. "Without magic, there is no way." I let the computer send and receive data unconsciously, watching the frames of data updated on the screen. I don't know when I was enlightened: I found that the data frames received from the original software seemed to be slightly different - it seemed to be a little slower. I checked it with an oscilloscope, and it was true: there was a little delay between the data bytes sent by the original software! The truth is out! It really came without any effort! So there was yesterday's breakthrough success: let the mobile phone APP add a 100 millisecond delay between each byte when sending data . The deadline for the competition has not yet arrived. Next, I can continue to improve the mobile phone APP . It's not a substantive problem. I can start preparing to submit the documents. 2021-7-7
|