It feels as if it has been forever since I started to work on this project and I am not done yet. So far I was able to build a brainwaves appliance controller using a PSoC5LP chip, a Schmartboard prototype board and an infrared remote control code learner in a Cypress CY8CKIT-001 evaluation kit. Both worked well separately but when I put them together in the same PSoC5LP chip I ran into problems. In my previous blog post I showed how I implemented the brainwaves appliance controller together with the infrared code learner in the Cypress CY8CKIT-001 evaluation kit, and I mentioned that it looked functional. Yes, it did for the experiments I tried at that time, which I covered in the previous blog post. After that I started a more thorough testing of all combinations of functions and modes. During this testing I discovered a combination of steps that sometimes locks up the system. For example if I set the system to learn two codes in sequence from a DVD player remote control and then transmit one of the codes using the emulated eye-movement sometimes the system locks up. To unlock it, I had to reset the PSoC5LP, but transmitting the same code would lock the system again. This problem did not show with remote control codes learned from other remote controls I tested.
So, I have spent most of the time after my previous update troubleshooting this problem and a few other software bugs that showed up during this testing activity. The most difficult part was the intermittent nature of this problem, so I had to repeat the sequence of commands a few times to see the problem. I started the troubleshooting process by looking at the difference between the codes of the DVD player remote control and a working remote control. To visualize the transmitted infrared code I used two types of infrared sensors, one that measures the raw signal and another one that outputs the demodulated signal. The two sensors are mounted on the prototype board shown in the figure below, and the outputs are probed with a Tektronix TBS 1202B-EDU oscilloscope.
First I measured the infrared carrier frequency of the two remote control units. The signal from the working remote control unit is shown in the figure below:
The upper waveform in blue represents the raw signal that contains the infrared carrier component. The lower waveform in yellow represents the demodulated signal. The oscilloscope’s built-in frequency measurement shows 39.53kHz for the channel 2 waveform (blue trace), which is the carrier frequency.
The non-working remote control waveforms are shown in the following picture:
The measured carrier frequency is 40.3kHz, which is close to the 49.53kHz measured for the working remote control, so I concluded that the carrier frequencies of these two remote control units are close enough not to be the cause of the problem I was troubleshooting.
Next I “zoomed” out to see the entire transmitted packets for these two remote controls. The following plot shows the data packet transmitted by the working remote control.
At the beginning there is a preamble that synchronizes the demodulator in the receiver. Following the preamble it is the actual data code after which there is a quiet section until the next data packet. I used the built-in cursor function in the TBS 1202B-EDU oscilloscope to measure the length of the quiet region, as shown in the picture. The measure value, which is displayed on the right side, was 39ms.
Then I measured the transmitted data packet of the non-working remote control, as shown in the following picture.
First impression was that this data packet looks totally different compared to the working remote control. I also used the cursors to measure the length of the quiet region as 14ms.
The lengths of the quiet regions were different between the two remotes, but other things were different, too. After many hours (and days) of debugging I found out what was happening. Here is the schematic of the data processing inside the PSoC5LP chip:
The system identifies the end of a data packet by measuring the length of the quiet region. This is done by Timer_4 in the schematic above, which sends an interrupt request to the MCU after each data packet (end_of_code_ISR). The threshold for deciding if there is an end of code was set to 35000 counts, which was equivalent to 14.583ms, as shown in the configuration form. For the working remote control this value was just fine because the length of the quiet region was 39ms, but for the non-working remote control measured length of the quiet region was 14ms, which was marginal to the 14.583ms setting. So, sometimes the end of code was not detected resulting in overflow of the receiving array. After lowering the threshold value the system worked fine. I still cannot explain the lock-up state (it must be additional things happening in the program caused by this overflow), but now it does not happen anymore.
This was one of the problems; I am still discovering software bugs, but so far they’ve been easy to debug and fix. So I am not done with the verification, and I estimate I will spend the next few weeks continuing this testing. I really want to be confident that everything works well before designing the printed circuit board and the rest of the assemblies for this brainwaves appliance controller project.
That’s it for now; I will come back with a new update as I get more work done.
Best Wishes,
Cosmin
