With the display fixed, I set out to do some alignment and adjustment on the TS-850. One thing I encountered was an issue with the attenuator. The 850 has two front panel buttons to switch in 6 and 12 dB attenuators, or both for 18 dB. One thing I had noticed was that the 6 dB attenuator seemed to work, but any time the 12 dB attenuator was switched in it completely killed the signal. Looking at the schematic, the only thing I could spot as a cause for that would be resistor R3 being open. I decided to pull the RF board and investigate.
With both attenuators off, relays K1 and K2 are both actuated. The signal from the antenna passes through K1 and K2, bypassing resistors R1 and R3. When the 6 dB attenuator is switched on, K1 de-energizes and puts a 6 dB resistive divider (R1/R2) in the signal path. The same method is used for the 12 dB attenuator (R3/4), activated by dropping relay K2.
Once I got the RF board out, the bottom of the board plainly showed that I was not the first one here. Portions of the board underneath the attenuator section were scorched, some SMT resistors were missing, and a 1/4 W resistor was soldered in place of R1. There were signs that some other components were damaged as well. I unsoldered and removed the “rework” resistor and found it to be the wrong value. Oddly, the board doesn’t match the diagrams I found in the service manual I found on line — a couple of the resistors have been replaced with pairs of resistors in parallel. That added some additional challenge to the process as I figured out the changes.
Eventually I found that something had damaged both R1 and R3. I found 1/8 W resistors of the correct values (51 and 150 Ohms – I had 50 and 150, close enough) in my parts stock. With those soldered in place of teh defective SMT parts, I put it all back together and powered the rig back up, and got… nothing. Static. My little Elecraft XG2 signal generator was pushing 50 mV into the antenna jack, and the rig couldn’t hear a thing. I fed the signal directly to L3 and was able to hear it – weakly. So, back out comes the RF board.
Some probing with the DVM found a near dead short (1.4 Ohms) from the tail end of the attenuator at K2 to ground. Obviously that was a problem. Eventually I found capacitor C3, a little 100 pF SMT part, shorted. I removed it from the board and re-tested – now I can clearly hear the signal from the XG2, AND both the 6 and 12 dB attenuators work as they should. I don’t have a replacement for C3, but it’s part of a low-pass filter that I’m not terribly worried about right at the moment. I’ll pick up a 100 pF cap and replace it at my next opportunity. I also don’t know why it failed in the middle of a repair. It obviously wasn’t shorted before I started troubleshooting this issue, as I was able to receive signals off the air. All I can figure is that maybe it was physically damaged but not completely failed, and the probing or heat from the nearby soldering iron did it in. No matter – capacitors are cheap.
Now, on to the next issue — the S meter. It doesn’t “S”. Even with a 50 mV signal, there’s no reading on the meter; I’ll have to go through the alignment steps again to see if I can figure that out. Unfortunately that part of the procedure calls for a more capable signal generator than what I have. I should be able to get in the ballpark with the XG2. The service manual calls for 6 dB and 32 dB – or 1 uV and 40 uV. The XG2 will generate signals on 80, 40, and 20 meters at 1 or 50 uV. I should be able to set the S meter to read pretty close, assuming I don’t run into some OTHER issue that requires ripping the radio apart again.
Note: edited 7/28/25; I refined this by removing one diode and dropping the supply voltage a bit.
A few days ago, I replaced the dim and occasionally flickering CFL backlight from my TS-850 with a length of LED strip light. At first I was pretty happy with it – until the first time I tried to transmit, that is.
To recap, I ran power from the power switch white lead (switched input DC voltage) as I had seen in a couple of Internet posts. I ran that through a total of four 1N4001 diodes in series. The 13.8 V supply voltage really drove the LEDs too bright, and two diodes provided enough voltage drop to make it more reasonable — though as I used it, it became apparent that it really could have used another series diode. The second pair of diodes were bypassed by the display dimmer switch. All well and good; it seemed to work fine.
Then I connected a new power supply thoughtfully provided by a friend (thanks, Dan!), connected a dummy load, and went about setting up the rig for use and testing the power supply’s performance. I set the supply voltage at 13.75 V, and as soon as I started transmitting into the dummy load I noticed that the display would dim quite a bit. In fact, if I set the dimmer switch on (display dimmed) and transmitted, the display would blank entirely. Not good!! It turns out that the white wire on the power switch – well, I don’t know what all is between it and the input; the schematics in the TS-850 service manual are almost impenetrable. Wherever it’s coming from, that line will sag down to 11 V or even lower when the rig is transmitting. Totally unregulated. Obviously I needed a better solution.
It occurred to me that, since I’d replaced the capacitors on the display board, maybe the original backlight would be OK. I re-installed the tube and re-connected the inverter and fired up the transceiver – but the display was pretty dim. After seeing it nice and brightly lit by the LEDs, I wasn’t about to go back to squinting at that. The serial number on my rig indicates it was manufactured in December of 1993; I guess thirty-odd years is a bit of a long time to expect a CCFL backlight to stay healthy. I spent a little time looking for a suitable replacement tube, but aside from not finding one with the right length, I have no idea what voltage is being produced by the inverter – and I’m really not in the mood to screw with it.
After some pondering, I settled on a new approach. I ordered some DC-DC boost converters from our favorite purveyor of just about everything (Amazon). These will take a wide range of input voltage – 2 to 24 V claimed – and convert it to a higher output voltage – 5 to 28 V they say. All I need is to bump the regulated 8 V power up to around 12 V to drive the LED strip. I can adjust the output to get the brightness I like, then switch in the diodes to drop it a little for the dim display setting. These boost converters cost well under a buck each, so I’ll keep a couple around just in case they don’t last as long as I do. I’ll make sure to bag one or two up, along with a replacement LED strip, to go with the transceiver when I (or my heirs) sell it. I’m not going to bother posting a link to the Amazon item because I’m sure in six months it will be a dead link. Just search for “DC-DC step up converter” or similar and sort through until you find a suitable model for you. You could also design one from scratch for extra ham credit.
I designed the circuit below to be as flexible as possible. You don’t need to modify the dimmer switch board; it remains entirely untouched. No soldering to the power switch. All of the wiring is completely on the display board. I happened to have a couple of small SPDT relays with 12 V DC coils on hand, but designed it so that you could use much any relay that has a normally-closed contact (so, SPST-NC or SPDT). These relays can be had dirt cheap. The coil voltage just needs to be 12 V give or take a little; nothing in this whole exercise needs to handle more than maybe 130-150 mA.
About the only inconvenience I ran into is that the DIM switch circuit doesn’t go directly to the CCFL inverter connector, so you’ve got to solder a wire to one of the ribbon cable connector pins. Not a huge deal. No major modifications to the display board are needed, but you will need to cut the small trace that runs from Pin 2 of CN1 (the display dim signal) to one of the SMT resistors in the board. That circuit feeds a PWM driver chip, and the circuitry there will prevent the relay from releasing once it’s turned on. That means if you dim the display, you can’t un-dim it until you turn the rig off.
In this circuit, the 8 V supply is picked off of the original inverter input connector and fed to the DC-DC converter. The output of the converter is set to 12 V or give or take a bit, whatever level gives an appropriate brightness for the LED backlight. The output of the boost converter is connected to the relay coil as well as the relay’s NC contact. The other side of the relay coil is connected to the DIM switch input from the front panel, which is grounded to dim the display and otherwise floats.
The LED backlight modification. After some experimentation, I removed one of the two series diodes.
With the display switch set for full brightness, the relay coil is not grounded and the relay is not energized. Current flows from the DC-DC converter to the LED backlight through the NC contact of the relay, bypassing the diode.
With the switch set to the DIM position (pushed in), the switch grounds one side of the relay coil and energizes the relay. Current now reaches the LED strip through the diode, which provide enough voltage drop to dim the display. Diode choice is not terribly important and can be changed to suit your individual preference for the difference between full brightness and “dim”. You could add a second diode in series if needed. My LED strip draws around 130 mA at full brightness; a 1N4148 would probably do the job as well. I just didn’t happen to have any on hand, which is strange given the thousands and thousands I’ve bought over the years for various kits I sold.
Installation is pretty straightforward. I removed the CCFL tube and slid the adhesive-backed LED strip behind the LCD, then used a piece of tubing I happened to have on the bench to reach through and make sure it was securely stuck down all the way through. A piece of dowel would be good too. I removed the inverter and its connectors entirely – no sense leaving that there with the tube gone. I used CN3, the inverter supply connector, for the ground and 8 V inputs to the boost converter. I soldered the diode assembly directly to the relay, then used some hot-melt glue to stick the relay to the board. The DC-DC converter then mounts onto the relay with more hot-melt glue – just be careful to keep anything from shorting. There’s enough room to sandwich a little spacer of balsa or plastic or something in there if needed. The converter I used has an adjusting pot that I made sure was facing upward, so I could adjust it from the top.
I left the LED strip unsoldered during the initial power-on “smoke test”. I had no idea what voltage the little board would be putting out. It turned out to be 18 V. I adjusted that down to 12 V and powered the rig off. Then I soldered the LED wires in place and powered on again. I tested the dim function and found it to be too dim on that setting, so I tweaked the voltage a bit to give me a good display on both settings. This will depend on your particular LED strip, but in my case I ended up with the output of the DC-DC converter set to 13.3 V. My first iteration of this used two 1N4001 diodes in series; I later switched to using a single diode and reduced the supply voltage to 11.5 V. That gave me about 10.75 on the dim setting, and the display looks great either way.
Now, why so complicated with the relay? Can’t you just use the dimmer switch directly without the relay? Well… sort of. Unfortunately, the way that switch is connected on the little switch daughter board, isolating the pins to use for this is a challenge. I ended up having to de-solder it from the board, cut off a couple of leads, and re-solder it. It’s too much surgery and is irreversible. I ended up buying a replacement from eBay; fortunately, it was relatively cheap, but obviously no new ones are being made, and I wanted to present a solution that involved as little butchering as possible.
Since this is a modification that may confuse someone encountering it for the first time, my plan is to pack up the schematic, a spare boost converter or two, and a spare chunk of LED strip and keep it with the rig. Some day someone else will probably own this transceiver, and they may appreciate not needing to reverse engineer all of it.
And finally, yes, I did see the packaged solutions available from a couple of places. Both are coming from outside the US, with all of the delay and shipping expense (and uncertainty) that comes with it. They’re also pretty spendy. I figure I’ll have under $2 worth of parts wrapped up in this project, and a left-over pile of little DC-DC converters and several feet of LED light strip that will probably soon adorn my 3D printer or something.
I’ve been running a server at home for a lot of years. Over the past 2 or maybe 3 decades, our server has provided Windows network shares and workgroup services, a repository for DVR’ed TV shows and movies, PBX functions with Asterisk, DNS, email, and more. Before all cable Internet providers started blocking incoming port 80 and 443 traffic, it hosted our simple family web site and even webmail at one point. One by one I’ve moved on, migrated, or replaced all of those – except email. Postfix and Dovecot IMAP are really the last things I’ve been using the local server for in the last couple of years. I do still run an ad blocker function in a Raspberry Pi.
The server is on old hardware bought 13 years ago – an Intel Atom D525 motherboard and a similarly old 1TB Seagate hard drive. The Ubuntu OS is long out of support and I have very little confidence in the life left in the hard drive. It’s been weighing on my mind recently. On top of all that, if I get hit by a meteorite or a bus or whatever… it’s going to be a nightmare for someone to figure everything out. It’s high time I retired that box; it owes me nothing.
I looked at a number of options. I could move email to a hosted VM – but it’s really a nightmare maintaining and trying to work around the many companies that block ALL mail for most popular hosting companies, regardless of using SPF, DKIM, and DMARC. I looked into a Microsoft business basic account. I considered letting my domain registrar do it, since they’ll provide webmail service. Each of these has advantages and disadvantages, and some are more expensive than others.
In the end, I discovered that you can set up your own custom domain in iCloud and use iCloud email. I don’t see us going back to Android phones, so that’s fine with me. All it takes is a few minutes with iCloud settings and a few TXT and MX records in DNS, so everything is easily reversible should I decide on a new path later on.
Now we’ll see how well Apple filters SPAM and phishing emails. I have spent countless hours over the years trying to eliminate the torrent of this crap that we receive every day, with pretty good results. A combination of Postgrey and some pretty extensive Postfix header and body check filters have eliminated most of the unwanted crap. I’m hoping it doesn’t all reappear again.
Next on the block is moving my small Asterisk system out of my house. It works exceptionally well, but of course if we have an internet outage it’s off line. As I hope to provide VOIP phone service to a couple more family members, I’d like something more reliable.
For years now, I’ve been using Asterisk for our home phone line (as well as one for our rental property business). One persistent issue has been getting SIP phones to act like regular non-PBX extension phones. You know — where two people in different parts of the house can use two phones on the same call.
Asterisk has shared line appearance (SLA) features, but this is designed to make it work like an old key system PBX. Not really the way we want it to work. If John is on a phone call and Jane picks up another extension, Jane can’t join the call — she just gets a new outbound line. Most of this is by design. For one thing, in most non-home settings you really don’t want just anyone to be able to join your call. If you want to add someone, you use the conference feature to dial their phone and add them. In a home setup, though, it’s a hassle and it’s complicated — since you don’t necessarily know which extension a person is using, especially if you’re using cordless phones. Asterisk is really not developed for home use; for some pretty obvious reasons, it’s mostly used by businesses. It is, after all, a PBX.
The solution I’ve used thus far is a regular analog cordless phone system (Panasonic, Vtech, etc.) and an ATA adapter like the Grandstream HT801. That device connects your analog phones to Asterisk. This approach is good, but it’s not a perfect solution. You can’t do things like use your cordless phones to make more than one simultaneous call (unless you have a multiline cordless phone and an HT802). These are also typically consumer grade phones, with limited displays and battery life. The quality of cordless phone systems has most definitely not improved over the past few years.
I want to try out some of the new Wifi SIP phones for a number of reasons, but I want to do it without losing the basic advantages of the consumer type cordless phones. What I finally came up with is a decent solution that combines the best of both worlds. Now if John is on a call and Jane picks up the phone, she can place a new call without interrupting John. She can also, however, join John’s call if she wants.
In my Asterisk dial plan, I added a new extension to my internal context. Dialing *11 will join your call to an existing call if one is in progress. I do this with the BridgeAdd() application and the CHANNELS() function, like this:
exten = _*11,1,NoOp(Join call)
same = n,If(${CHANNELS(trunk)})
same = n,BridgeAdd(${CHANNELS(trunk)})
same = n,EndIf()
same = n,Hangup()
CHANNELS(trunk) works because any channel that is created for an external call has that pattern in the channel ID. In my pjsip.conf file, I have my trunk connections configured with that string in the name – so it’s an easy target for the regex parameter passed to CHANNELS().
I’ve got a Wifi SIP phone on the way that has some programmable softkeys. I suspect I’ll find a good use for one of those to make operating them as simple as a Panasonic DECT phone.
First let me acknowledge that there are many ways to accomplish this. An easy solution for me would have been to simply use dyndns.com, no-ip.com, or one of the other commercial DDNS services supported by my router. For various reasons, I decided not to use one of those. Actually I did use duckdns.org for a while, but there were occasional issues that I got tired of dealing with.
I’m currently using Porkbun for DNS. They’re cheap, reliable, and have a decent user interface. They, like many other DNS services, also provide an API to make changes programmatically, without needing to log into their web site and make manual changes.
In my case, I have a shell script that runs as a cron job every 5 minutes. It checks my router for the WAN address and compares it to the last recorded address. If the two are not the same, it emails me and runs a Python script to update DNS.
I realize that some of this is pretty specific to my setup. Still, it might be a useful starting point. I found the Python script to update Porkbun DNS on their web site. The command to check the WAN IP address at the router may work for yours, or you may need to take a different approach.
#!/bin/bash
# Read the old IP address from a file. The EOL will go into a variable we don't use. This is necessary.
read OldIP b < /home/dale/myipaddress.txt
# Get our curent IP address from the router.
OUTFILE=~/myipstatus.txt
MyIP=`ssh -o StrictHostKeyChecking=no [username]@[router.ip] "ifconfig eth0 \
| grep inet | sed -e 's/.*addr:\([^ ]*\) .*/\1/'"`
while [[ $MyIP == "" || $MyIP == "192.168."* ]] ; do
sleep 10
MyIP=`ssh -o StrictHostKeyChecking=no [username]@[router.ip] "ifconfig eth0 \
| grep inet | sed -e 's/.*addr:\([^ ]*\) .*/\1/'"`
done
if [ "$OldIP" != "$MyIP" ] ; then
echo "`date`" > $OUTFILE
echo "Found new IP $MyIP, which is different from our previous $OldIP!" >> $OUTFILE
echo "Updating Porkbun DNS entries..." >> $OUTFILE
python3 ~/porkbun/porkbun-ddns.py ~/porkbun/config.json <mydomain.com> <hostname> >> $OUTFILE
mail -s "IP address change detected" <myemail@domain.com> < $OUTFILE
echo $MyIP > ~/myipaddress.txt
else
echo -n "." >> $OUTFILE
fi
In practice, this can result in a 5-10 minute lag between the time your IP address changes and the time your DNS is updated. If your ISP changes your IP address frequently, it may be too long. In my case, our ISP only changes our IP on rare occasions — typically less than once a year.
Again, there are other approaches, but most will not update DNS entries in your own domain. You can get around this to a certain extent by using CNAME entries, but this was the best way that I found to update my own domain’s DNS.
Once upon a time, residential home Internet connections — cable modem and DSL being the choices at the time — were unfiltered and un-firewalled. This had good and bad aspects to it. You may or may not have been firewalled off from your neighbors. I remember a guy who worked for me demonstrating on the TV news one night how he could see every Windows PC in his neighborhood, and send print jobs to random peoples’ printers if he wanted to. Even after they wised up to that little bit of “openness”, it was still possible to run your own services — mail, web, and so on.
Since then ISPs have come a long way. Residential cable, DSL, and fiber connections, often topping out at 1 GB or even higher, are tightly restricted. Your ISP really wants to support only web prosing and gaming, and most certainly do not want any services running on their network. No web servers, no email (in or outbound). Anything inbound on ports 80, 25, and often 443 are blocked, as is outbound port 25.
So, you’ve got your own little web server you run for your own blog (like this one)… or one you run for a nonprofit, club, whatever. You’ve got your own domain and want to run your own email. The solution is usually some combination of a hosted VM, Google, what have you. But it can get a little expensive, and of course you’re dependent on others for critical bits and pieces of your infrastructure. I can’t take all of that pain away, but I can maybe help to reduce it somewhat.
So let’s look at the issues you may face, and how to solve them. I’ll detail each solution in subsequent blog posts, with solutions that may work for you as they have for me.
Your IP address is dynamic, and you need reliable DNS. This can be fixed using a script to detect when your IP address changes, and update your DNS accordingly. It’s not perfect in that there will be a delay before the IP address change is detected and updated, but if your IP only changes occasionally it’s “good enough”. Of course there are dynamic DNS (DDNS) solutions that will do this as well, if you don’t mind paying for them. I’m a cheap bastard and I like a challenge, so I rolled my own.
Your ISP blocks connections on port 25 (SMTP). This is pretty much going to require an external mail relay. I have yet to find a way to get the rest of the world to use any port other than 25 for SMTP connections… it really is too bad there’s not a DNS based way around this, like a SRV record (see RFC 6186). Until that happens, I use a small external hosted VM relaying mail on a different port. It could actually be a lot simpler, but I prefer to keep our actual email on a server here, at my house.
Your ISP blocks incoming traffic on web ports 80 and 443. Easy. Nginx is your answer, what was the question?
The fun part is sizing this stuff. If you’re used to working in a corporate environment like I have been for the past (mumble) years, you’re thinking, “OK, a 4 CPU 16 GB machine for a mail server, than another one for the proxy… that might be OK… ” Nah. You might be shocked at just how little power it takes to do this stuff. After all, we’re just passing packets around. The TLS encryption is the most heavyweight thing being done, I think. If I had a solid place to hang a Raspberry Pi where it would have a static IP and no filtering of privileged ports, it wouldn’t break a sweat — though I’ve had too many of them just stop working to trust them for this kind of stuff, really.
Nomorobo is a fantastic service. It’s not perfect; plenty of illegal phone spammers are using throwaway numbers and/or illegally spoofing caller ID numbers to make calls that appear to be from random numbers — usually in your own area code. Short of using a strict whitelist, I don’t see a real way to get rid of those. Using Nomorobo, though, will dramatically cut down on the number of junk calls you will receive.
There’s a little problem, though… while many phone providers offer the service (we’ve been using Ooma), they don’t appear to offer the service to individuals or small businesses who run their own phones.
I ran my own Asterisk PBX for several years, supporting our home phones as well as a separate line I used for work, and even a toll-free number for my side business. Life was good for quite a while, but eventually it got to be quite a hassle trying to keep up with all the junk calls. Then my VOIP carrier changed their pricing to make them much less attractive from a cost standpoint. Eventually we switched to Ooma. They’ve been good, but not without issues. The Telo Air occasionally loses communication with the mothership, and if you don’t see the red light you won’t know that your phones aren’t working. The cost has gone up, now running over $20 per month for the Ooma Premier, which includes what I consider to be some pretty basic features — like call blocking, for example.
Now we have some family members who need a home phone, but I just can’t bear to see them get roped into paying really stupid monthly costs for a simple phone line. That, and our Ooma service is getting more expensive and (it seems) less reliable by the year. Time to switch back. But how can I keep Nomorobo? It would be a tough sell to do without that!
Well, Twilio to the rescue! They offer a Nomorobo lookup API that costs a tiny amount per lookup — $.003, or 0.3 cents per incoming call lookup. Conversely, that’s 333 lookups per dollar. Not bad, I’ll gladly pay that to avoid taking telemarketing or scam robocalls. Now, if only we could get Nomorobo to list all of the numbers used by political “push polls”, recorded messages, and other political campaign silliness!
Twilio’s call rates are not outrageously high either, and their monthly costs for DIDs (phone numbers) are pretty reasonable. The only thing I’ll fault them on is too much hassle to set up CNAM for your outbound calls, so unless you go through that process everything shows up as the number only with no CID name. Flowroute is MUCH better for this, so I route most of my outbound calls through them.
So — how to get Asterisk to do the lookup? After several hours of playing around with this, I found that it’s pretty easy to do. While it wouldn’t be terribly helpful (or smart) for me to post my entire dialplan here, I’ll include enough to get you going. I put this very near the top of the context I use for incoming calls from PSTN trunks. There’s no sense in burning CPU cycles on a call if you’re just going to drop it anyway.
First, you’ll need a Twilio account. They’re even nice enough to give you some credit on your account if you’re new, and it’s enough for quite a bit of learning and development work. I funded my account so I can use them for international calls — they’re ridiculously cheap for most destinations. They’re also a good solution if you want to get DIDs in countries outside the US.
Once you have a Twilio account established, use your account SID and auth token to set CURLOPT() with your username and password. This will be used in the next line to make the curl call to the API:
same = n,Set(CURLOPT(userpwd)=username:password)
Now, make the call to Twilio’s API to get the spam score. The result is a block of JSON that gets saved as TWILIO_RESULT:
same = n,Set(TWILIO_RESULT=${CURL("https://lookups.twilio.com/v1/PhoneNumbers/${CALLERID(num)}?AddOns=nomorobo_spamscore")})
Since we’ve got a block of JSON, we’ll need to extract the one wee bit we need. Fortunately Asterisk has a solution for that as well, so we don’t need to resort to anything drastic like a shell command:
same = n,Set(SPAMSCORE=${JSON_DECODE(TWILIO_RESULT,add_ons.results.nomorobo_spamscore.result.score)})
Now we use that result to drop the call if it’s spam. A simple Hangup(2) tells the caller that their call was rejected:
same = n,GotoIf($[ ${SPAMSCORE} = 1]?dropcall)
Later in the dialplan, after we’ve done the whole “call the user, drop to voicemail if they don’t answer, yadda yadda yadda” we have this:
same = n(dropcall),Hangup(21)
The Hangup(21) tells that their call was rejected. There are other, even more creative codes to use… like these (list courtesy of voip-info.org):
Like some other ISPs, Cox blocks all incoming access to port 80 on residential connections. They also use DHCP to assign dynamic IP addresses, which can can and do change occasionally — especially when you reboot your router. That’s fine in most cases, but can be a real pain in the ass if you run any local services that you need to access from outside the home. For example, if you run your own email and want to use IMAP, you’re likely going to need an SSL certificate. You need a way to have your DNS update to point to your new IP when it changes.
One way to do all of this without paying subscription fees is with Duckdns and Letsencrypt. Duckdns is a free DNS service with an easy to use API that can be updated by a script when your IP address changes. Letsencrypt is a free SSL certificate CA; I can’t say enough good things about Letsencrypt and encourage you to support them with a donation as I have.
So. First we can use cron to run a command that updates our duckdns IP address every ten minutes or so.
Simple, right? Now we have a hostname that always points to our own home IP address – or at least always does within ten minutes of an IP address change, which is probably good enough for most purposes.
Now for the SSL certificate. Letsencrypt will happily issue free a 90 day SSL cert for your domain. Normally, one runs a script from cron that renews the certificate if the cert is expiring in less than 30 days. IF you can expose port 80 to the web, even temporarily, then life is good — just run ‘certbot renew‘ once a day, or even once a week, and everything happens for you in the background. If, however, your ISP filters port 80… well, there’s the pain-in-the-ass part. The certbot script renew script will only work if you have port 80 open to the web. I haven’t found a way to get Letsencrypt’s server to use any other port to reach your web server, so forwarding a non-blocked port (8880, for example) to your local server’s port 80 does you no good.
All is not lost; it just means a bit more work. Letsencrypt will also issue certificates using DNS challenges for authentication, placing specific TXT records to prove that you have control of the domain or subdomain in question. The process looks like this:
certbot certonly --manual --preferred-challenges dns -d example.com-d -d example-com.duckdns.org
The certbot script will tell you to create TXT records in DNS for your domain, and will wait for you to do so before proceeding. You can use your DNS provider’s web or API interface to add or change the TXT record accordingly. Duckdns now supports TXT records in addition to A records, and updating yours is simple:
Once you’ve verified that the TXT records are there using, say, ‘dig _acme_challenge.{my_domain}.duckdns.org TXT‘ — simply hit ENTER to let the script finish. You should end up with a renewed SSL cert.
My previous ISP didn’t block port 80, so I never had to do any work at all for this. I ran the ‘certbot renew’ command from cron once a day, and it automatically updated the certs for me. Now that port 80 is no longer an option, I will need to manually renew the certificate every 90 days. I’ll actually do it at around 75 days, because Letsencrypt helpfully sends out emails to let you know when your certificate is within 15 days of its expiration.
Time flies when you’re ignoring a blog, right? I’ll catch up.
The Mercedes is gone. After everything I’d fixed on it, when the transmission decided it didn’t want to work reliably any more — screw it, I was done. It was an awesome car to drive, but not so much fun to own. I replaced it with a much newer 2018 BMW 540i Xdrive, which has been wonderful.
Still flying occasionally, but nowhere near as much as I should or want to.
Nothing’s happened with the Mustang, other than getting the engine put back together.
We’ve picked up a couple more rental houses; that enterprise is going pretty well overall.
We switched from Visible to T-Mobile. Visible had great service when we signed up; it slowly degraded to barely usable. TMO has been better, but not great.
I just dumped CenturyLink. Our CenturyLink fiber service has been down since Wednesday morning (it’s Friday now). It took me three hours to get through to a human there, on the phone, who told me they could have someone out Saturday morning. Absolutely appalling service. We were up and running on Cox within an hour of leaving the house to go pick up their equipment.
Now I remember why I didn’t like Cox’s equipment… zero flexibility, no control over your own local network at all. You can’t even set your own DNS, so my Pi-Hole is not functional. I’ve got new equipment coming this afternoon. New cable modem, router, and mesh wifi.
I left my long time employer (a bank) a little over a year ago and now work for another bank.
The symptom: No (or intermittent) heat in the front seats of a 2007 W221 S600.
The vents blow cool to cold air most of the time.
Changing the temperature zone setting has no effect.
Turning the climate control system OFF for a minute or so, then back ON will result in warm air blowing briefly, cooling off rapidly — as if there is hot water in the heat exchanger, but no flow of hot water from the engine.
XENTRY/DAS diagnostics show all temperature sensors working.
Fixes tried:
Replaced AC water valve. The old one was in need of replacement; the top water hose neck snapped off during removal and the rack & pinion gear was jammed with some debris, so it likely wasn’t working. The valve is a non-Mercedes sourced part, unbranded, likely Chinese sourced like everything else. $40, quality appears to be quite good and the fit was perfect.
Tested valve operation with XENTRY/DAS. Using the actuations top open and close the valve result in hot air (CLOSED) and cool air (OPEN), so the valve is mechanically and electrically operational.
Used diagnostics to teach-in and normalize all actuators, flaps, and air control potentiometers. This had no effect on the symptoms.
I wanted to reverse the wires to the valve at the plug. My hypothesis was that the motor was simply installed backward, resulting in the valve running opposite the direction commanded by the HVAC system. Since it’s an open loop system, the front SAM would have no idea that this was happening. Unfortunately, I had no convenient place to swap the wires. I ended up determining that it was indeed wired backwards internally. A new part from a Mercedes dealer (thanks, Husker Auto Group!) fixed it.
