In the past few weeks I made some developments on the alternative solutions.
First I made a hardware decoder for timecode signal, which eliminates the analog audio processing in software or firmware. And I also added an external I2S DAC to the system to be able to use and test all 4 channels of audio. Here is a video of the new hardwarare unit. It is still the MIDI controls the iPad application but the midi signal is made directly from the vinyl audio.
This version handles the vinyl speed correctly while scratching. I made some modifications. I’m using TIM8 input capture while not scratching and to jump into and out of scratch mode (touch on and off events) because it’s more punctual to measure frequency.
And I’m using TIM3 in encoder mode while scratching, because with that I can count the ticks of both the rising and falling edges of both channels of the encoder, without any interrupt or code. It gives me 4 times the resolution than if I counted the input capture interrupts.
And another video with master tempo and synch working properly.
This is the continuation of the hooking up post. I had some experiments with the encoder interface. I set up another timer, to read the encoder interface TIM3 value regulary (each 5 ms). I found out, that the resolution of this method is far from enough. And the latency is 5ms or more.
The counter value fluctuates between 23 and 24 for the 5ms period. Now I only have 2 values between 0 and +8% pitch positions. It means that my pitch granularity is 4%. I cannot recognize if I move the pitch slider between 0-4%. It is obviously not enough for correct beatmixing, I need 0-4%- 0,1% or 20-80 values for the pitch range. I need to modify my original idea and not using the encoder interface mode.
I wrote about my working HID interface in the previous post. Now I can send data to my laptop in a convenient way in a simple HID report because I wrote a Delphi program to send and receive HID reports years ago.
Next step is to wire the Tascam TT-M1 scratch control unit to the board. As STM32F4 series have quadrature encoder interface in some timers, I can easily count the pulses without any line of code in my main loop or without using more interrupts or processor load.
In my previous post I mentioned that my audio interface crashes after a while. I also mentioned that my guess it is because of the non-scheduling my different USB transefers. So I did it.
I used the SOF (Start-of-frame) interrupt as my 1ms timebase.This interrupt has to be enabled in the USB device configuration part, because it’s disabled by default. In other words simply replaced my HAL_GetTick() function which is based on the counter incremented each 1ms in the SysTick interrupt. My similar function is the USB_GetTick() which is based on the counter incremented each 1ms in the USB SOF interrup.
This is the new waveform I have. The start of the HID report transfer is in a fixed time slot. It comes after 718us always. And it completes of course in the end of the frame.
Now I have a composite device in my STM32F4 Discovery board. It contains a USB Audio 1.0 interface (speaker) and a MIDI (in&out) interface. I need a convenient way to send the speed, direction from the Tascam unit, and other debug data for the mouse application to my laptop than MIDI. I can write my own Windows program for HID communication easier than one for MIDI. And on the other side, for the future, HID will be a better way of communication with DJ programs. So let’s move on to add HID in and out.
I got back to the audio part of the project for a post. I heard annoying pops and crackles during the playback, and after about 3-4 seconds, a complete distorted sound. I know that I left this part unfinished before.
At last, I routed my 1&2 channels (out of 4 channels) to the audio DAC of the Discovery board with a simple software loop that splits my audio buffer into two separate buffers after the samples came in. My audio buffer stored 16 packets, which means 8ms latency and about 6KByte buffer. The original Audio Class implementation uses 80 samples, and has some other strange thing that I mentioned earlier.
I hooked up my mouse to the Discovery board. I cut the wires from the Nordic chip to the PAW3205 chip. I soldered my wires to PAW3205 and connected them to SPI1 on the Discovery board.
I promised to write a post about how this optical mouse and the sensor works. I disassambled the mouse and connected the USBee logical analizyer to the SCLK, SDIO, MOTSWK pins. As I mentioned, it contains a PAW3205DB sensor chip.
The chip uses a half-dupex SPI bus to communicate with the integrated Nordic 2.4 GHz transciever chip. The SPI clock frequency is 166.6 KHz. Further details and timings of the communication can be seen in the datasheet, as well as the schematic for wireless mice.
First I captured the startup sequence and decoded what happens. There is a configuration process, before the mouse starts to send the motion data.
00 30 read product ID1 default
01 50 read product ID2 default
09 00 read write_protect enabled
89 A5 write_protect disable?
09 A5 read write_protect disabled
01 50 read product ID2 default
89 00 enable write_protect
06 04 read configuration MOTSWK level sensitive, 1000 CPI
86 00 write configuration set CPI to 400
06 04 read configuration CPI 1000
86 04 write configuration CPI 1000
1F 3A unknown
85 BC write operation mode enable sleep1 and sleep2 mode, force enter sleep2, LED shutter enable
–5ms
86 08 write configuration power down mode
—550 ms
86 80 write configuration full chip reset
— 8ms
85 B9 write operation mode force wake up
86 80 write configuration full chip reset
86 06 write configuration CPI 1600
06 06 read cinfiguration CPI 1600
–32ms
00 30 read product ID1 default
02 86 read motion status motion, no Y owerflow no x verflow, 1600 CPI
03 FF read DeltaX +127
04 00 read DeltaY 0
–8ms
00 30
02 86
03 FF +127
04 FB +123
00 30
02 86
03 FB +123
04 FE +126
There are some strange things for me. I won’t do so much config in my code. Some of them seems to be useless.
One important thing is, when the receiver is not connected to a computer, the startup sequence stops after the power down command.
Motion is queried each 8ms. Which is strange again, because the HID descriptor says, the polling interval is 4ms. It seems to be that this mouse is not a well engineered thing 🙂 The query consists of a Product ID read, which is for checking if the controller and the sensor chip is in synch. (If not, there is a re-sync method on the clock line). The motion status is read after. If there was motion, DATAX and DATAY is read, otherwise not.
The MOTSWK pin is a signal, it stays low while there is valid data in DATAX or DATAY registers. I think I wont need this signal for my application.
That’s it. It seems to be fairly simple for the first glance. Next I’m going to hook up the STM32F4 DISCOVERY board to the optical sensor chip, and figure out an optimal way to communicate with it.
iPad turntable controller 