Let's Design and Build a (mostly) Digital Theremin!

This is the first time I've heard of a homopolar toroid.  Was that for a current sensor (e.g. Rogowski coil)?

In the electricity distribution domain, an homopolar toroid is a 20cm toroid ferrite with a secondary winding only, the tree phase wires pass through it and then you get an image of homopolar current at the secondary winding. In a lab, if current injection box has not enough power you need to manually wind a primary winding (e.g. 100 turns for 100 A injection). 

"https://patents.google.com/patent/US6414475" 

Yes, I would have loved to have such a machine, or only the same idea, at that time. I used a kind of weawing shuttle instead. Depending on whether the toroid can or cannot open, the experience is not the same...

Coiled Plates

So I've done a few rough experiments using three different coils as the Theremin antenna:

A CW (clockwise) solenoid, a CCW solenoid, and a spiral, all made of household solid copper wire.  Note that the spiral can be flipped over to make it CW or CCW.  I measured total Q while sitting on directly on top of a 10mH solenoid, and again with 30mm or so of spacing between the antenna and the 10mH solenoid.  As expected, total Q decreases a bit when the plate coil is counter wound to the 10mH and placed closer to it.  So nothing earth shattering or dramatic to report.

I also messed around in a spreadsheet, calculating the relative capacitance of a 2D rod type antenna to one's finger, where the finger is held a constant distance from the rod, but moved up and down the rod.  Playing with conductive weighting towards the ends of the rod, it seems one needs to massively weight the ends of the rod (vs the center) to make the up and down finger movement produce a constant response, and this response is only sorta linear when the finger is quite close, like 10mm or 20mm.  Moving closer you get a "hollowing out" of the middle, moving farther gives slightly better linearity over a solid conductive rod, but the returns are fairly marginal, and I have no idea how to very heavily weight conductivity to the rod ends like that.

The whole point of this investigation was to see if 
1. a nearfield plate could be better linearized over the area being addressed by the hand, and also 
2. if the plate could be made less of a Q damping "shorted turn" when placed very near the coil.  

The initial conclusion for (2) is that a spiral seems to allow closer placement to the coil.  For (1) the spiral turns could be concentrated more towards the outer edge.  But a spiral wouldn't have the full intrinsic C of a solid continuous plate.  What might work is a plate with a hole in the center, the diameter of which somewhat larger than diameter of the 10mH coil.  This and narrow radial slot cut in it to minimize the current loop might help to defray damping.  The hole, and extra plate material at the edges going 90 degrees backward might help to accentuate the edge response, improving linearity a bit.  The covering insulation might limit closeness and prevent hollowing out of the center response.  This is my next TODO experiment.

A square plate somewhere between 150mm to 200mm on a side feels to me like a comfortable playing surface size.

Hi, this is Klaus Hoffmann. I'm new to both Theremins in general and D-Lev in particular. I'm no musician either.
I started this weekend to dig into the subject and found https://d-lev.com/ an interresting project, especially as the device is played by real musicians in concerts.

The first step I reached is to build the Hive assembler on Windows 10 and with it build the *.spi and *.mif files from theremin.hal. I want to share my experience.

Preconditions:
- install Cygwin and here especially `gcc-g++`
- download and unzip https://d-lev.com/source/d-lev_sw_source_2024-01-08.zip
- delete hive_sim and hive_sim.o (obsolete executable and object file)
- backup 94e67227.spi, hive_0.mif, hive_1.mif, hive_2.mif, hive_3.mif (will be generated)

1) fix hive_pkg.cpp
In the function `str_trim()` replace these two lines:

    while (ch_is_white(str.front())) { str.erase(str.begin()); }
    while (ch_is_white(str.back())) { str.pop_back(); }

    while (str.length() && ch_is_white(str.front())) { str.erase(str.begin()); }
    while (str.length() && ch_is_white(str.back())) { str.pop_back(); }

Without this fix, the program will terminate silently without writing the output files when the string `str` reaches zero bytes length.

2) build hive_sim.exe
open cygwin64 terminal
cd "\path\to\d-lev_sw_source_2024-01-08"
g++ hive_sim.cpp -o hive_sim.exe -std=gnu++11

Build instructions for the *.spi and *.mif files.

1) execute hive_sim.exe
It will read theremin.hal and recursively all included files: pkg_boot.hal, pkg_ch.hal, pkg_defs.hal, pkg_enc.hal, pkg_filter.hal, pkg_float.hal, pkg_hcl.hal, pkg_int.hal, pkg_lcd.hal, pkg_midi.hal, pkg_mod.hal, pkg_noise.hal, pkg_osc.hal, pkg_params.hal, pkg_pitch.hal, pkg_spi.hal, pkg_str.hal, pkg_tuner.hal, pkg_uart.hal, pkg_ui.hal, pkg_vol.hal, thd_0.hal, thd_1.hal, thd_2.hal, thd_3.hal, thd_4.hal, thd_5.hal, thd_6.hal, thd_7.hal.
It will write
- hive_0.mif, hive_1.mif, hive_2.mif, hive_3.mif
- 94e67227.spi

2) press any key to continue...
3) enter "quit" (without the quotes) and enter

Compare the written files with your backup. They shall be identical.

As I understand on the FPGA a soft processor core named Hive is implemented (https://d-lev.com/research/Hive_Design_2022-10-24.pdf).
I guess the .hal files are the "Hive assembly language" files and hive_sim.exe is both assembler and simulation of the Hive core.
If anyone can point me to the language description I'd be interrested.
I'm also interrested in the use of the generated .mif and .spi files. Where do they go to in the next step?

"In the function `str_trim()` replace these two lines:" - gerbold

Ah, thanks for that Klaus!  Have to watch C++ strings like a hawk, and C++ programs tend to crash and panic in mysterious ways.  I much prefer Go.

"I guess the .hal files are the "Hive assembly language" files and hive_sim.exe is both assembler and simulation of the Hive core."

Yes.

"If anyone can point me to the language description I'd be interrested."

This is a to-do for me, though I do think a lot of it can be inferred from the use cases, comments, and processor white paper.  The assembler / simulator flags stack faults and interrupt misses (running out of real time), which are the more difficult things for the programmer to manage.  Not sure at this point if future versions of the D-Lev will continue with my Hive processor or not - if not then HAL will probably be largely abandoned along with it.

"I'm also interrested in the use of the generated .mif and .spi files. Where do they go to in the next step?"

The *.mif files are copied to the main FPGA directory and a build done with Quartus.  This provides the default "golden" SW load in the FPGA block rams (BRAMs) so the D-Lev is un-brickable.  The *.spi file is loaded to the EEPROM via the librarian software, and its CRC is checked at boot - if the CRC is OK then the EEPROM*.spi load replaces the BRAM default *.mif load and boot proceeds.

This is my understanding of the KiCad files:

main connects to
+- J1/J2 = FPGA module Waveshare CoreEP4CE6 with ALTERA Cyclone IV chip EP4CE6E22C8N
+- J4 Pitch AFE = d-lev_afe
+- J5 Volume AFE = d-lev_afe
+- J6 Right Encoders = d-lev_encoders (4 turn and push knobs to control the menu in the LCD)
+- J7 Left Encoders = d-lev_encoders (4 turn and push knobs to control the menu in the LCD)
+- J9 LED Tuner = d-lev_tuner_driver + d-lev_8mm_tuner (7 segment digit + star with 13 LEDs)
+- J10 (LED, MUTE, MIDI, MAIN, LINE, RxTx, 5V, GND)
+- J11 (power supply)

d-lev_footprints.pretty - required for the layout (do not yet know how to import into KiCad)
JLCPCB -> probably pre-packed gerber data for https://jlcpcb.com/

One needs
1 Waveshare CoreEP4CE6
1 d-lev_main
1 d-lev_tuner_driver
1 d-lev_8mm_tuner
2 d-lev_afe
2 d-lev_encoders

Is there a BOM (bill of materials) that lists all the connectors, resistors, cables, LCD, buttons, ... that are required?

Quartus seems to be the tool from Intel.
https://www.intel.de/content/www/de/de/products/details/fpga/development-tools/quartus-prime/resource.html
As the Lite edition supports Cyclone IV FPGAs, it is probably sufficient.

"This is my understanding of the KiCad files"  - gerbold

Yes to all.

"Is there a BOM (bill of materials) that lists all the connectors, resistors, cables, LCD, buttons, ... that are required?"

This is a list of parts, mainly for my accounting purposes, but it may help: https://d-lev.com/source/D-Lev_kit_parts.ods

"Quartus seems to be the tool from Intel."

Yes.  Not trying to discourage you, but if you don't want to regenerate everything from source, all of this is pre-compiled and pre-build for you in the source files, including the gerbers.

I tried to compile the FPGA project.
Is this the correct way and which is/are the required output file(s)?

- start Quartus Prime Lite Edition
- open d-lev_fpga_source_2024-01-08\Q20_v0.9.4\ep4ce6e22c8_demo_board.qpf
- menu Processing -> Start Compilation

In the processing window a bunch of lines is shown and finally
>Info: Quartus Prime Timing Analyzer was successful. 0 errors, 3 warnings
> Info: Peak virtual memory: 4915 megabytes
> Info: Processing ended: Fri Sep 27 08:05:55 2024
> Info: Elapsed time: 00:00:03
> Info: Total CPU time (on all processors): 00:00:02
>Info (293000): Quartus Prime Full Compilation was successful. 0 errors, 10 warnings

As a result I see a bunch of new files named ep4ce6e22c8_demo_board.* being created.

continue in Quartus Prime Lite Edition to convert the programming files
- menu File -> Convert Programmig Files...
    - Open Conversion Setup Data...: ep4ce6e22c8_demo_board.cof
    - scrol down and press [Generate]
    - Do you want to overwrite [output_file.jic]? [Yes]

The generated output_file.jic is different compared to the ziped file.
This may or may not be a result of my
"Quartus Prime Programmer Version 23.1std.1 Build 993 05/14/2024 SC Lite Edition"
is higher than the originally used
"Quartus Prime Programmer Version 20.1.0 Build 711 06/05/2020 SJ Lite Edition"

Yes.  Any generated *.mif files should be placed in the Q20_v0.9.4 directory before you run Quartus (it will replace those already there).

After the Quartus run:
1. File | Convert Programming Files... | Open Conversion Setup Data...
2. Select "ep4ce6e22c8_demo_board.cof"
3. Generate | (Overwrite?) Yes

This generates "output_file.jic" which is the programming file.

After this you can connect the programming dongle, power up the FPGA demo board, open the programmer, and select the setup the hardware.  It can get a little weird at this point, you may need a bit of hand holding depending on which OS you use (Linux in particular is really weird here).