Live Streaming & DIY Microphone


During 6 and 1/2 of my 7 years of college (part time), I was President of and helped build a student organization for LGBTQ+ students and their allies. Every year we host an event comprised of speeches from students, faculty, and staff that I video tape. Eventually we began streaming the event live on Facebook. The event is always around the 2nd week of October.

Now I’m an alumni advisor to the organization and I’m still recording/live streaming the event. I wanted to post about how I do this, mainly for my future reference.

Recording/Live Streaming Setup

The event is held in a small, but beautiful chapel on campus. I normally setup the camera in the back corner of the room and the speaker is in the opposite corner in the front of the room. The recorded audio has always been decent, but it could definitely be better.

I connect the camera’s A/V output into the composite input cable on the TV Tuner, which is then plugged into the computer’s USB port. I use the software that came with the TV tuner or VirtualDub to set the channel on the TV tuner to the composite input. Then I can close VirtualDub or the TV tuner software and open OBS.

Computer Specs

OBS Setup

In OBS, I have a scene with just a photo source (the club’s logo). In another scene, I have the TV tuner’s video and audio sources. I run the photo a few minutes before we start and then switch over to the camera when the event begins. I do the actual recording in the camcorder at 1080p 30fps. Composite video has a standard resolution of 480i or 576i, so I set OBS to stream at a resolution of 640 x 480 to Facebook using a bit rate of 2000 kbps.

DIY Electret Condenser Microphones


I am NOT responsible for any loss or damage resulting from the use or building of this project. PLEASE make sure your camera/device accepts this type of powered microphone before connecting it. I am NOT going to be responsible for any damage you may cause by building or using this microphone.

Parts list

  • 6 Feet of 2 Conductor Audio Cable – I used thin coax cable, RG-174.
  • 2 Mono 3.5mm (1/8″) Phone Plugs (male)
  • 2 Capacitors (100nF – Code 104) – I used the ceramic disc type.
  • 2 resistors (680 Ohm) – Value should match the impedance of the microphone elements you purchase.
  • 2 Microphone Elements – I used PUI Audio AUM-5047L-3-R.
  • 2 short lengths of PVC Pipe – I used 1/2″ Sched. 40 PVC cut at 6.5″.
  • 2 PVC End Caps – Size needs to match the PVC pipe.
  • Spray Paint
  • 1 Length of wood or PVC pipe cut at 26″
  • 2 Bolts – 6-32 size. Use a length that will go through 1/2″ PVC (OD = 0.84″) and your piece of wood/pipe. (I used 2.5″ bolts and they were a 1/2″ too long).
  • 8 Flat Washers – #6 Size
  • 2 Hex Nuts – 6-32 Size
  • 2 Wing Nuts – 6-32 Size
  • Heat Shrink Tubing (various sizes)
  • Air Conditioner Foam Filter
  • 3 Panel Mount 3.5mm Phone Jacks (female)
  • 9V Battery
  • 9V Battery Holder


  • Soldering Tools
    • 15W Soldering Iron
    • Solder – I used 63% Lead / 37% Tin with a rosin core.
    • Desoldering Wick
    • Flux Pen
  • Pliers
  • Wire Cutters
  • Wire Strippers
  • Tweezers (optional)
  • Lighter
  • Audacity Recording Software

I’m not going to go into painting the PVC and putting the bolts through it. Nor will I cover cutting the slots in the PVC pipe or the sewing of the windscreen foam.

How to Build The electronics

wiring the microphones & connectors

  1. The first thing I did was solder the connectors onto the ends of the coax or audio cable. Make sure you put the plug’s cover on first. I did not care about interoperability so I soldered the center conductor of the coax to the center pin and the shield of the coax to the sleeve of the connector. Put one connector on each 3 foot piece of cable.
  2. Put heat shrink over the cable first. (we’ll shrink this later).
  3. On the other end of the cable we’ll solder the microphone element to the wire. The center pin goes to the positive and the shield of the coax connects to the negative on the mic element. Try to do this quick and precisely or you’ll ruin the mic like I did on my first try. I had to order another one after ripping the solder pad off the mic element. The mic’s solder pads are tiny, about 1mm wide by 3mm long. Don’t short the two solder pads either.
  4. Slide the heat shrink tubing up enough to cover the wires a bit, but do NOT cover the back of the microphone element. Shrink it over the wire. Don’t over heat the wire or mic element.
  5. Make sure you’re soldering the center conductor to the positive solder pad on the mic element. I messed this up on one microphone and could not figure out why neither microphone worked with the circuit.
two microphones
Two completed microphones.

create the circuit

Mono Directional Electret Microphones – Power Supply & Mono to Stereo Connection Schematic

Using the above schematic, we’ll create the circuit used to power the microphones.

Basically, the resistors provide bias to the microphone elements. The value of these 2 resistors should match the impedance of the microphone elements you bought. Mine were 680 Ohm. These resistors should be 1/2 Watt resistors.

The capacitors block the battery’s direct current (DC) from getting into the camera. While capacitors block DC current, they allow AC current, such as an audio signal, to pass through.

NOTE: Some capacitors are polarized and must be installed with the positive leg facing the microphone elements. If you install the capacitor backwards you could damage your camera and/or the microphone elements. The capacitors used in this schematic are NOT polarized.

Project box with power switch.
Project box with power switch

Test for DC on the Output before use

Just to be on the safe side, I tested for any DC voltage on the output before I plugged this into my camera. Plug in the battery, turn the switch on and test the output connector with a multimeter for DC voltage to make sure there will NOT be any DC getting into the camera. If your multimeter detects DC voltage on the output do NOT plug it into the camera. Go back and check your connections.

Project box output side
Output Side of Project Box

Creating the Stereo Effect (Extremely Basic)

This part is a little over my head, but according to what I’ve read, you can create a stereo effect in one of many ways. Since I couldn’t find microphone elements with the correct polar patterns to create a single stereo microphone, I made two mono microphones that get connected to the circuit which connects both of them to the stereo mic input on my camera. By separating the microphones at least 24 inches using the piece of wood or pipe, you will get a “stereo” sound effect.

completed microphones showing spaced stereo positioning
Showing Spaced Stereo Positioning of Completed Microphones

Matching the microphones

Typically, when a stereo microphone is built, the two elements are “matched” to be sure that the sounds they record are the same volume and gain on both the left and right channels. This is done so that the volume of one channel is the same as the other, else the audio would not sound right.

I personally did NOT match my microphone elements. I am not recording professional audio and I needed something cheap. I also wasn’t 100% sure how to do it at home (it can be done fairly well at home though).

That said, the two microphones are from the same manufacturing lot, the audio sounds the same on both channels to me and the gain of each channel is extremely close when looked at with Audacity.


The microphones sound MUCH better than the camera’s internal microphone. They’re fairly clear and provide decent audio for a “home” video. The volume of the recorded audio was almost exactly the same as the source audio I recorded.

The internal camera microphones sounded quieter than the source I was recording. While they were clear, the audio didn’t sound as clear or as full as the microphones I built. The audio from the camera sounded like it was too deep.


I used many sources and forums to find the information necessary to build my microphones. I originally was trying to build a shotgun microphone (a very directional microphone employing an interference tube design), but there was significantly more information on building a DIY Directional Microphone, so I went with that. I did research over the course of a couple of weeks trying to learn enough to build this project. The circuit is the basic manufacturer’s recommended design for a single microphone element that has been modified to connect two microphone elements to the same battery and stereo output connector.

I want to thank everyone who put this information out there for others to use.

Schedule Update of Stripped.csv File

I recently had a gentleman, Richie M6XRM, contact me on how to do this. It proved to be quite the challenge.

Instructions & Script

The information and how to has been posted on my GitHub page along with the script (you will need to supply your own URL to the stripped.csv file). Below I’ll explain the issues we encountered while trying to configure this automatic update. I can’t say that this is the best or only way to do this, however this is how I did it and I can confirm it works.

Issues & Fixes

Issue 1

One of the biggest issues was writing the script on Windows and converting/keeping the line endings of that script as unix line endings so they’re compatible with linux. I used Notepad++ to write and edit the script before uploading it to GitHub. Apparently it is not enough to save the file as a UNIX bash/sh file type. At the bottom of Notepad++ it says what the line endings are and I never noticed it. The DOS line endings created a lot of issues when the script was run on the Pi.

Fix 1

The fix for this in Notepad++ is to click Edit > EOL Conversion > Unix and then save the file as a UNIX bash/sh file with the extension “.sh”. The fix in the nano text editor is to press CTRL + x, then y, then ALT + d, then enter.

Issue 2

The other major issue was that system cron on the Pi does not understand rpi-rw even when it is run inside the script which is being run as root.

The cause of this is that rpi-rw is actually an alias set in the bash profile for the logged in user. Since cron runs as it’s own thing/shell separate from the logged in user (pi-star), it doesn’t understand rpi-rw or at least it didn’t understand it for me or Richie.

Fix 2

The fix for this is to put the actual command that rpi-rw points to in the script instead of using rpi-rw. That command is as follows:

sudo mount -o remount,rw / ; sudo mount -o remount,rw /boot

I came across this page on Medium which explained how to convert Raspbian to a read-only filesystem which is what Pi-Star uses. At the end of the page it talks about creating an ro and rw alias to quickly switch the filesystem between read-only and read-write. That’s when it dawned on me that this is the way the Pi-Star developers handled the read only operating system and that rpi-rw/rpi-ro are aliases.

A huge thank you to Richie M6XRM for his patience with me in figuring this out and for being so understanding while I was recovering from surgery.

We just hope this helps someone else and explains a bit of the mystery behind the rpi-rw and rpi-ro aliases.

Tyler N3TDM

Scheduling Pi-Star Reboot

Why schedule a reboot?

I wanted to schedule the DSTAR repeater, that I manage, to reboot automatically every Monday morning. The reason for this is that sometimes Pi-Star stops working and/or freezes up. This typically happens every 2 or 3 weeks of uptime without a reboot. My best guess is that due to the log files not being deleted after rotation, that the Pi software gets “clogged up.” I’ve found settings that are supposed to rotate the logs and only keep a certain number of log files, but those do not appear to work, at least not on our setup.

Since these log files are deleted on every reboot of the Pi, the next best idea in my opinion is to schedule a late-night/early-morning reboot once a week.

I used cron to schedule a reboot. I also use cron to schedule automatic linking and unlinking of reflectors. Pi-Star uses a specialized version of cron that adds a “run as user” option.

Find the Expert Cron Editor Tab

  1. The first step is to log in to your Pi-Star dashboard. This can be accessed by opening a web browser and going to http://pi-star.local/ or http://pi-star/ or the IP address/host name of your Pi-Star repeater or hotspot.
  2. After logging in to your Pi, click on “Configuration” in the upper right of the page.
  3. Next in the upper right of the page click on “Expert”, then on the following page in the bottom row of links on the top of the page click on “System Cron.”

Understanding cron

  1. You will see a text box open with a bunch of seemingly cryptic text. Each line is a cron task that is scheduled to happen at a certain time. It should look similar to this:
    Shows pi-star expert cron configuration
  2. About halfway down the text box you will see the following line:
    # m h dom mon dow user command
  3. This line tells us the format of each cron task. The # symbol indicates a comment and tells cron to ignore that line.
    The “m” indicates “minutes”, “h” indicates hours, “dom” indicates Day of Month, “mon” indicates month, “dow” indicates Day of Week, “user” indicates the user the the command should run as, and “command” is the command you want to run at the given time/day. Refer to the chart below for options for each position in the line.
Enter the minute you want to run the task at or * for any minute.
Enter the hour you want to run the task at or * for any hour.
(Day of Month)
Enter the day of the month you want the task to run at or * for any day of the month.
Options: 1-31 (date of the month)
Example: * = any day of the month
Example: 5 = 5th of the Month
Enter the month you want to run a task or * for any month.
Options: 1 = January, 2 = February, 12 = December
Example: 4 = Run in April
Example: 1,6,12 = Run in January, June, & December
Example: * = Run any month
(Day of Week)
Enter the day of the week you want to run the task or * for any day of the week.
Options: 0 or 7 = Sunday, 1 = Monday, 2 = Tuesday, 3 = Wednesday, 4 = Thursday, 5 = Friday, 6 = Saturday
Example: 0,3 = run on Sunday and Wednesday
Example: 7 = run on Sunday
Example: * = run any day
user Enter the username of the user that you want to run the command.
Options: pi-star, root
Example: root
command Enter the command to run. This can be a script or a single command or multiple commands.
Example: reboot
Example: pistar-link unlink && pistar-link ref063_c
The above example will unlink the repeater and then link to REF063C.
  1. Normally when you add a cron task it can be anywhere in the cron file, new lines are typically added at the end. In Pi-Star this works too, except that for some reason a line containing the reboot command should be put in as the first cron task in the list, right below the line we see in step 2 under “UNDERSTANDING CRON”.
  2. Note that if you add anything to the end of the file that you must maintain the new blank line at the end of the file. If you’re at the end of the last cron line, press the down arrow on your keyboard. If you see the cursor move down to the blank line, you’re all set. If the cursor doesn’t go down, just press “enter” on the keyboard to add a blank line at the end of the file.

How to Schedule a Reboot

  1. In order to schedule a reboot every Monday at 4:55am, I entered the following line as a cron job.
    55 4 * * 1 root reboot >/dev/null 2>&1
  2. Don’t forget to put it at the top of the cron job list, before the first cron job line, but after the line: # m h dom mon dow user command
  3. Now we have a job that says, at 4:55AM every/any month, every/any day of the month, on Monday, run the reboot command as the root user, and do not show output.
  4. The >/dev/null 2>&1 means that whatever text output the command generates won’t be shown or logged. For more info on what this part of the command means, see this forum post on Stack Exchange.

More Info on Cron

If you use the cron expression generator from Free Formatter, it will not work with Pi-Star, but it will give you the idea of how to write a cron expression. It also lists all the different options and has plenty of great examples of how to use cron.

Week 14 – Pi Case

I’ve been trying to experiment with TinkerCAD to model a 3D printable box for this project. I have the bottom of the case designed with the mounting holes for the Pi. I haven’t been able to figure out how to design the top of the case so that it snaps into place.

Here is a top view of the bottom part of the case.

Here is a top view at an angle.

I have no prototyped this so I can’t even say for sure that the mounting holes are correct, but I believe they are. I did make the holes slightly smaller to allow screws to bite into the plastic.


Week 11 – DMR Deviation & Case

I enabled DMR last week and spent some time configuring it. This week I had to set the DMR transmit deviation in order to get it to work.

Essentially setting the TX deviation for DMR is the same as how I set the transmit deviation for DSTAR in the beginning. I used a service monitor and checked the deviation level while the repeater was transmitting. It was lower than it should have been, so I increased the level in the expert MMDVMHost editor on the line that said DMR Level. This adjusted the deviation for just DMR, leaving the deviation alone for all other modes.

I also created a box/case for my project out of a large crayon box that I found at WalMart for about $3.

  1. I used a template for the Pi to drill four holes in this box for some #4 screws to mount the Pi and MMDVM duplex. I also put a piece of acrylic between the Pi and this case so that it wouldn’t be pressing against the back of the Pi.
  2. I then cut out a hole for the size of my 3.2in Nextion Display.
  3. I also drilled holes around the display cutout to mount the display in place.
  4. I used plastic from an old ice cream container to create a bezel to go around the display since part of the display doesn’t show anything and is instead used for the touch screen controller/wiring.
  5. I added two external antenna connectors. I bought two male to female jack/panel mount SMA connector extensions for about $6 each and then I added some right angle SMA connectors (male to female) 5 for about $4.
  6. For the external antennas I drilled the holes in the box as far apart as I could and installed the female jack connectors through the hole.
  7. Then I screwed a right angle SMA connector on each jack.
  8. Next, I used a couple right angle SMA connectors on the MMDVM hotspot/repeater board.
  9. Finally, I installed all of the electronics.Here is the finished case.

Week 10 – Many Solutions & DMR

Last week, I had three problems, two of which I couldn’t fix.

Problems & Solutions

Problem 1 was solved by recompiling the Nextion Driver and reinstalling it by hand.

Problem 2 was that the repeater wasn’t starting up as quickly as it does at home. I thought this was caused by the enterprise WiFi at my university. I’m fairly certain that was the problem. This issue seems to sort itself out, if you’re patient. I’m certain the issue is due to the time it takes the Pi to authenticate with the enterprise WiFi. I did add a button to restart the WiFi from the Nextion display. It is two simple commands.

I added a button to the display’s “System” or utilities screen and made it execute the following commands.

sudo ifdown wlan0 && sudo ifup wlan0

Basically this turns off the wlan0 interface and turns it back on.

Problem 3 was that I couldn’t always access the PiStar dashboard over the WiFi. That problem wasn’t really a problem. Again it had to do with the time the Pi takes to authenticate with the WiFi. I found that if I wait about a minute or two after the display shows the IP address, then go to the displayed IP address in a web browser, the PiStar dashboard appears as it should.

As for the issue with the self-assigned IP address over the ethernet connection, it doesn’t appear to matter. The two devices will communicate with one another given enough time.

A problem I ran into this week was that the repeater board doesn’t always initialize and connect to the software on the raspberry Pi, this is fixed by stopping and starting the mmdvmhost service, which can be done from the Nextion display.

Enable & configure dmr

The first thing I did was enable DMR and I did this from the expert settings for MMDVMHost instead of the main configuration tab. The reason for this is that when you configure from the main tab and click apply changes, you can lose settings you set in the expert MMDVMHost page.

    1. Navigate to the expert editor for MMDVMHost.
    2. Scroll down to DMR.
    3. Your settings should look like this:
    4. What do those settings mean?
      Enable – On (1) or Off (0)
      Beacon – Turn on (1) or off (0) beacon or a transmission that happens every so many minutes/hours to tell others your repeater exists.
      ColorCode – A number for your repeater, typically 1, but may be different. A radio set to a color code of 1 cannot talk to a station with their color code set to 2.
      SelfOnly – Limit DMR communication to your own callsign only (a Private hotspot)
      DumpTAData(1) – Talker Alias data (person’s name/location/callsign) are dropped (0) – Talker Alias data (person’s name/location/callsign) are sent to the RF stations. This can cause issues with some radios, but I set mine to off (0).
      ModeHang – The number of seconds the repeater should stay listening for DMR over RF after the end of a transmission.
    5. Next scroll down to the DMR Network section of MMDVMHost.
    6. What do these settings mean/do?
      Enable – Turns on the DMR network/gateway to the internet.
      Address – The IP Address of the Master Server you’re using. I used Brandmeister 3108 and found its IP address on the Brandmeister website under “Masters.” I believe this is only visible after you’ve logged in with your callsign and Brandmeister password.
      Port – This is the port on the server you’re connecting too. Leave this as the default.
      Password – The password to the Master Server. The default for most Masters is “passw0rd”. That’s a zero in place of the letter “o”.
      Slot1 – This turns on or off slot 1. DMR transmissions are sent in one of two “Time Slots.” Repeaters can receive and carry on two completely separate conversations with one on each time slot.
      Slot2 – This turns on or off time slot 2.
      ModeHang – This is the number of seconds the repeater should remain in DMR mode after the end of a network transmission.
    7. Click “Apply Changes”

Add Brandmeister panel

  1. Next I added the Brandmeister control panel to the repeater’s admin dashboard. I followed these instructions.
  2. This is what the Admin Dashboard looks like after adding the Brandmeister control panel. This screenshot was taken before I changed to the US Brandmeister 3108 Server which is why it says “BM United Kingdom” as the DMR Master.


Week 9 – Many Problems

This week, I downloaded a Nextion Display layout created by PD0DIB and modified it to include a system control page and an information page. After trying out the Nextion Driver Installer created by ON7LDS, I could get the screen to display information one time, but after switching pages, the data would disappear. To solve this problem, I looked at the Nextion Driver Installer script and followed most of the steps manually. Doing it this way also allowed me to switch the displayed CPU temperature from celsius to Fahrenheit. This pretty much solved the issues with the display.

In the Nextion Driver Installer Script, I followed this section:

if [ "$ND" = "" ]; then
    echo "+ No NextionDriver found, trying to install one."
    killall -q -I MMDVMHost
    killall -9 -q -I MMDVMHost
    if [ "$CHECK" = "PISTAR" ]; then 
        cp $DIR"/mmdvmhost.service.pistar" /usr/local/sbin/mmdvmhost.service
    if [ "$CHECK" = "JESSIE" ]; then 
        cp $DIR"/mmdvmhost.service.jessie" /lib/systemd/system/mmdvmhost.service
        cp $DIR"/mmdvmhost.timer.jessie" /lib/systemd/system/mmdvmhost.timer
        cp $DIR"/nextion-helper.service.jessie" /lib/systemd/system/nextion-helper.service
        if [ -e /etc/systemd/system/nextion-helper.service ]; then
            echo "+ there is already a link /etc/systemd/system/nextion-helper.service"
            echo "+ I'll leave it like that."
            ln -s /lib/systemd/system/nextion-helper.service /etc/systemd/system/nextion-helper.service 
    cp NextionDriver $BINDIR
    echo "+ Check version :"
    NextionDriver -V
    echo -e "+ NextionDriver installed\n"
    echo -e "+ -----------------------------------------------"
    echo -e "+ We will now start the configuration program ...\n"
    $DIR/NextionDriver_ConvertConfig $CONFIGDIR$CONFIGFILE

Basically all I did was the following:

  1. Stop MMDVMHost with “sudo service mmdvmhost stop”
  2. Download the Nextion Driver from github into the /tmp folder
  3. rpi-rw
    cd /tmp
    git clone
    cd NextionDriver
  4. Compile the driver by running “make”
  5. Then you should end up with a binary called “NextionDriver”.
  6. Copy the binary into /usr/local/bin with
    sudo cp NextionDriver /usr/local/bin/NextionDriver
  7. This was all done AFTER running on its own. So, my installation had all the helper files already installed before I ran through these commands.

Problem 2

The hotspot/repeater doesn’t startup right away like it does at home. I’m guessing this is because of the enterprise WiFi at my University. Sometimes the repeater starts right up and works perfectly and other times it does not work.

Problem 2 Solutions

  1. Create a simple script to reset the WiFi connection on the Pi and create a button on the Nextion Display Layout that would allow me to run this script.
  2. Use the same script, but have it run after the Pi is completely booted and add a line to restart the MMDVMHost service.

Problem 3

I could not always access the PiStar dashboard through the ethernet/crossover cable or through the University’s WiFi. Again sometimes I had no issues and other times it would not connect. At first I thought this was due to having both the ethernet and the WiFi running on the Pi, but after removing the ethernet, I had the same issue. I’m growing more suspicious of the enterprise WiFi. As for it not working over the crossover cable, I believe this is due to the fact that the computer is addressing itself with a self-assigned IP address (a 169 address). The problem appears intermittent.

Problem 3 Solutions

  1. Use the solutions for problem 2 as I believe the two problems may be related.
  2. Create a static IP on the Pi and the Computer for the ethernet connection.
  3. Change the PiStar firewall rule for the dashboard from “Private” to “Public.”

Going Forward

  1. Enable DMR and configure it.
  2. Install the Brandmeister control panel on PiStar.
  3. Program the DMR Radio.
  4. Create a blog post about programming the DSTAR and DMR radios.

I also wanted to create a 3D printed case for this project, however I am not sure I will have enough time to do that, especially with encountering these problems.