WZab's animated logo

Digital Wireless System for Electric Guitar

Polska wersja tego dokumentu
SVG image showing design of the Digital Wireless Guitar System
Please note, that the system described below is a FREE DESIGN provided WITHOUT ANY WARRANTY. If you build and use it, you do it on your own risk! Please note, that this is a RF transmission system, so you should be sure, that its use does not violate your local regulations!

The described system has been designed to match the following requirements: Of course there are different professional systems offering the above functions, but their price is rather too high for an amateur guitarist. On the other hand my system does not offer parameters like professional systems, but it may be built at reasonable price. The essential components include: Currently the system offers the following parameters: Current schematic diagram is available as the KiCad project, or as separate PDF files: transmitter, controllers' block, daughterboard with CS5343/CS5344 converter, receiver.
Current sources of the firmware are available as archive and (with the history of last changes) in the github repository, while a few earlier versions were also published on the alt.sources Usenet group. In the current version of the system the transmitter is mounted on dedicated PCB (full design is available in the KiCad project), placed in the Z32 enclosure. To place potentiometers behind the batteries, I had to select small potentiometers, and additionally to mill slightly the enclosure.
Overall view of the mounted transmitter is shown below:



Inside view of the transmitter



Inside view of the transmitter with batteries taken out and potentiometers visible.



The mounted transmitter PCB is shown in next two pictures:





The mounted receiver PCB is shown in next two pictures:





Transmitter's power supply

To assure efficient power supply, two NiMH rechargable batteries (may be replaced with alkaline batteries) are used, working with the step-up DC-DC converter based on MCP1640 chip. Such solution seems to be risky in a system designed to handle acoustic signals with high dynamic range. Therefore the boosted voltage is further stabilized with linear voltage regulators. It is also essential to use good quality decoupling capacitors. To switch on and off the transmitter, you should use the switch (not shown in the schematic diagram) connected in series with the batteries.

Software working with the system

The DWGS system is dedicated for use with the digital virtual amplifier/sound processor. In my case it was the guitarix or rakarrack working with the jack audio system under Linux. For recording and postprocessing I use the ardour.
With receiver's firmaware compiled in a standard way, the system is recognized as audio device providing monophonic sound in 24 bits(effectively 20 bits) sample swith 24 kHz sampling frequency. For processing of sound from different sources I usually use the jack system working with sampling frequency of 48 kHz. Necessary sampling frequency conversion and synchronization is assured by the "alsa_in" program (called as:$ alsa_in -d hw:2,0,0 -r 24000 -c 1 -n 2).
To allow operation with computers working under control of MS Windows, I have added the mode which emulates sampling frequency of 48 kHz. To activate it, you need to uncomment the line #define WGS_EMUL_48KHZ in the customize.h file. Even though the sampling frequency is the same in the DWGS and in jack, you should still use alsa_in program to assure correction of possible small differences of sampling frequency and to keep sound synchronized. In this case the alsa_in program should be called as $ alsa_in -d hw:2,0,0 -r 48000 -c 1 -n 2.

Why the DWGS system uses 24 kHz sampling frequency?

In fact the CS5343/CS5344 ADC works with sampling frequency of 48kHz, and during the first tests of the system I was able to achieve transmission of the true 24bit/48kHz digital sound. Unfortunately, due to the limited throughput of the RFM70 module, to assure such high transmission rate I had to switch off the "auto acknowledge/retransmission" functionality, which increases reliability of the transfer. It resulted in loss of quality due to dropped packets, so the final sound quality was worse than with current 20bit/24kHz transmission. If you have a module similar to RFM70 but offering higher throughput, you can relatively easy modify the firmware to achieve true 24bit/48kHz transmission.

Modification of MIDI commands sent by controlls

To provide high flexibility of the DWGS system, the user may define what MIDI commands should be sent when the button is switched or released and when the potentiometer's shaft is turned. The programming is realized like in my previous design "MIDI expression pedal with programmable footswitches".
Initially when a button is pressed the DWGS sends the MIDI "Program Change" command with program number between 1 and 4. Release of the button initially doesn't generate any MIDI command. Potentiometer's settings are initially sent as MIDI "Control/Mode Change" commands with control number between 80 and 82.
To change above settings you should send special USB control messages to the receiver (I use a simple program written in Python with "pyusb" library to achieve that).
To modify command sent when setting of a potentiometer is changed, you should send the control message of following form (Python syntax, using pyusb functions):
dev.ctrl_transfer(0x40,0xbN,0xB1B2,0xB3B4)
where N is the potentiometer's number (between 0 and 2), and B1, B2 i B3 define the first three bytes of the generated MIDI command, while B4 is replaced with the current setting of the potentiometer (when B4=0) or "inversed" setting of the potentiometer (when B4 is not equal to 0).
To modify command sent after pressing of the N-th button, you shoud send the control message of following form (Python syntax, using pyusb functions):
dev.ctrl_transfer(0x40,0x8N,0xB1B2,0xB3B4)
where N is the number of the switcho (between 0 and 3), and bytes B1, B2, B3 and B4 are the consecutive bytes of the generated MIDI command. The only exception is the fact, that if B1 is equal to 0, no command is generated at all.
To modify command sent after release of the N-th button, you shoud send the control message of following form (Python syntax, using pyusb functions):
dev.ctrl_transfer(0x40,0xcN,0xB1B2,0xB3B4)
where N is the number of the switcho (between 0 and 3), and bytes B1, B2, B3 and B4 are the consecutive bytes of the generated MIDI command. The only exception is the fact, that if B1 is equal to 0, no command is generated at all.
Example of the program used to reprogram the DWGS system is available here. If you define the appropriate udev rules file in your Linux system, you can achieve automatic configuration of the system, when it gets connected to the PC, or when the PC is switched on. For example in my system I have added the following udev rule: ACTION=="add", SUBSYSTEM=="usb", ATTRS{product}=="WZab Digital Wireless Guitar System 1", ATTRS{bcdDevice}=="0001", MODE="660", OWNER="root", GROUP= "audio", RUN+="/usr/local/midi/setup_dwgs_v1.py" If you want to modify the setup program according to your needs, you should probably read the following documents: USB MIDI class definition and table of MIDI messages.

Change of RF channel

Transmission of the sound and control data via DWGS may be disturbed, e.g. by Wi-Fi networks. Therefore the transmitter is equipped with two buttons allowing you to increase or decrease the number of the used channel by 8. To stay inside the unlicensed ISM band, the DWGS uses the 83 lower channels offered by RFM70 module. As 8 and and 43 are relatively prime numbers, multiple pressing of those buttons allows you to select any channel. On the other hand, change in increments/decrements of 8 channels allows you to quickly go sufficiently far away from the frequency occupied by Wi-Fi network.

Previous version of design and firmware

The previous version of the system is available as the KiCad project (schematic diagrams and TX PCB) and as archived sources of the firmware.