Using EDA Playground

So to write Verilog code you need to write a testbench.

// Code your testbench here
// or browse Examples
module tb();
  reg clk, reset;
  wire speaker;
  music dut (.clk(clk), .speaker(speaker),.reset(reset));
    $dumpvars(0, dut);
    reset = 1'b1;
    clk = 1'b0;
    reset = 1'b0;

      #10 clk = ~clk;

The #10 type things are delays.

The dumpfile thing is needed by edaplayground

The reset logic was necessary or else the submodule had unspecified values

Make sure to check the open EPWave box on the side

Everything needs to be wrapped in a module endmodule.

The .clk is specifying the parameter. the clk inside the parentheses is the reg I’m passing it.

I set reset high. Wait, then turn it low.

To end the simulation you need the $finish command.


// Code your design here
module music(clk, speaker,reset);
input clk, reset;
output speaker;

// Binary counter, 3-bits wide
  reg [2:0] counter;
always @(posedge clk) 
        counter <=0;
  		counter <= counter+1;
// Use the most significant bit (MSB) of the counter to drive the speaker
  assign speaker = counter[2];

specify how this module can connect to the outside world

<= is some kind of sequential assignment. It tends to be what is used in these posedge type blocks.

= is used to form aliases using the assign command

If else stuff is fairly self explanatory

begin end are the equivalent of {} in other languages


Openscad Text Cut

Need to save as a dxf

In Inkscape convert to path

Then select all nodes and click convert to line and add nodes.

Put it near to 0,0 corner so you can see it.


Put the files in the same place as the scad file


difference() {
	translate([-16, -5, 5]) {
scale([.6, .6, .6]){
		linear_extrude(height = 100, center = true, convexity = 10)



Gnuradio Delay Correlation

Trying to develop some software for coherent rtl synchronization. This is the first step, using internal gnuradio signal sources. Thinking that’ll we’ll use this setup + a synchronize button that will set the current delay. Or maybe sliders. Would kind of suck to have to synchronize manually every time, but not horrible. Maybe the synchronize button will set the slider values to the appropriate places. And could enable or disable all the extra processing with valve. Okay, did that. Set True to 0 default to 0 and false to 1 in gui checkbox. Then run that variable into the valve leading into all the correlation stuff.

Check this out. Learned some things. Stream to Vector packs such and such samples into a stream of vectors. Kind of ubiquitous in gnu radio, so I’m not sure why I didn’t know about this already.

That is what you need for the fft

When you change the vector size, you need to change the window size parameter in the fft too or else you get an error.


You’ll see that one way to calculate it is to fourier transform, conjugate multiply, then inverse fourier transform. We then plot this on a vector sink. And use the argmax to find the peak delay. It works really damn well in this simulation, but real world performance is to be determined. When the total delay is more than ~800 using vector size of 2048, it loses the peak. Negative delay wraps around back. That dip in the correlation is almost certainly due to the windowing done by the fft.


Got a hackrf. Sqeet.

hackrf_transfer -c 127 -f 100000000


hackrf_transfer -r /dev/null -s 20000000

Made  quick little fm transmitter.

Only goes a couple feet, so should be okay wherever you do it.

Also doing it on our ham freqeuncies, so doubly so


Audio source comes in from the microphone

Gotta resample

Should resample before fm-mod?

When I did, the signal looked better, but deviation from central frequency was way too high. Could low pass, but probably not the way to go

More to come probably