rct's notes

rtl_433 DSC sensor bit decoding.

2018-05-28T11:30:00.000-04:00

I'm finally going to submit a PR to rtl_433 to break out the DSC security sensor status bits. I thought I'd post the proposed output here in case anyone wants to comment. This is an update of my previous post: rtl_433 now decodes DSC 433 Mhz wireless securty contacts.

Sorry it has been nearly 3 years since I've posted the original. I've been using a Perl and later Python parser to analyze the messages.

A few notes:

The x*-bits are somewhat experimental.
Some bits, namely the "xactivity" bit are a little different depending on sensor manufacturer.

Some (4945) set the "xactivity" bit on event messages.
Others (4975) set the "xactivity" bit on the first heartbeat message *after* an event. So it can be used to detect if an event transmission has been missed.

There are two bits that seem to indicate tamper, I need to go back and check my logs a bit more carefully or run some additional experiments. I think one represents the tamper status, the other is more of a event indicator.

The tamper field looks at both xtampe1 and xtamper2.

I won't include message type, that was an experiment to test a theory that 2-3 bits might trepresent a message type..
Let me know if you've seen status values other than what I have here or if you spot something I haven't.

Here's a summary of the proposed output:

$ ./sensor-decode.py
Most Common WS4945 (Open, Closed, Heartbeat Open, Heartbeat Closed)
0xa1 0b10100001 {"closed": false, "event": true, "battery_low": false, "tamper": false, "xmsgtype": 2, "xactivity": true, "xtamper1": false, "xtamper2": false}
0xa3 0b10100011 {"closed": true, "event": true, "battery_low": false, "tamper": false, "xmsgtype": 2, "xactivity": true, "xtamper1": false, "xtamper2": false}
0xc1 0b11000001 {"closed": false, "event": false, "battery_low": false, "tamper": false, "xmsgtype": 4, "xtamper1": false, "xtamper2": false}
0xc3 0b11000011 {"closed": true, "event": false, "battery_low": false, "tamper": false, "xmsgtype": 4, "xtamper1": false, "xtamper2": false}

Most Common EV-DW4975 (Open, Closed, Heartbeat Recent Open, Heartbeat Recent Closed)
0x81 0b10000001 {"closed": false, "event": true, "battery_low": false, "tamper": false, "xmsgtype": 0, "xtamper1": false, "xtamper2": false}
0x83 0b10000011 {"closed": true, "event": true, "battery_low": false, "tamper": false, "xmsgtype": 0, "xtamper1": false, "xtamper2": false}
0xe1 0b11100001 {"closed": false, "event": false, "battery_low": false, "tamper": false, "xmsgtype": 6, "xactivity": true, "xtamper1": false, "xtamper2": false}
0xe3 0b11100011 {"closed": true, "event": false, "battery_low": false, "tamper": false, "xmsgtype": 6, "xactivity": true, "xtamper1": false, "xtamper2": false}

Motion Detector 4904P (Tripped, Heartbeat, Not tripped)

Glass Break - Tripped, Heartbeat (not tripped), Not Tripped & Tamper, Heartbeat w Low Battery
0x82 0b10000010 {"closed": true, "event": true, "battery_low": false, "tamper": true, "xmsgtype": 0, "xtamper1": true, "xtamper2": false}
0xcb 0b11001011 {"closed": true, "event": false, "battery_low": true, "tamper": false, "xmsgtype": 4, "xtamper1": false, "xtamper2": false}
0x8a 0b10001010 {"closed": true, "event": true, "battery_low": true, "tamper": true, "xmsgtype": 0, "xtamper1": true, "xtamper2": false}
0x8b 0b10001011 {"closed": true, "event": true, "battery_low": true, "tamper": false, "xmsgtype": 0, "xtamper1": false, "xtamper2": false}
0x80 0b10000000 {"closed": false, "event": true, "battery_low": false, "tamper": true, "xmsgtype": 0, "xtamper1": true, "xtamper2": false}
0xf3 0b11110011 {"closed": true, "event": false, "battery_low": false, "tamper": true, "xmsgtype": 7, "xactivity": true, "xtamper1": false, "xtamper2": true}

Flood Detector (N.O.) - Heartbeat OK, Tripped, Heartbeat & Tamper,
0xc2 0b11000010 {"closed": true, "event": false, "battery_low": false, "tamper": true, "xmsgtype": 4, "xtamper1": true, "xtamper2": false}
0x92 0b10010010 {"closed": true, "event": true, "battery_low": false, "tamper": true, "xmsgtype": 1, "xtamper1": true, "xtamper2": true}
0x93 0b10010011 {"closed": true, "event": true, "battery_low": false, "tamper": true, "xmsgtype": 1, "xtamper1": false, "xtamper2": true}
0xa2 0b10100010 {"closed": true, "event": true, "battery_low": false, "tamper": true, "xmsgtype": 2, "xactivity": true, "xtamper1": true, "xtamper2": false}
0xe2 0b11100010 {"closed": true, "event": false, "battery_low": false, "tamper": true, "xmsgtype": 6, "xactivity": true, "xtamper1": true, "xtamper2": false}

Here are the bitmask mappings used for the above:

0x80 = Sync bit? Always on, Invalid if not?
0x40 = Heartbeat Message (not an open/close event)
0x20 = Activity ?? (usage varies between manufacturers)
0x10 = Tamper, possibly tamper event/state change message, EOL missing?
0x08 = Battery Low
0x04 = ?? never seen set
0x02 = Closed/"Ok"/"Restored"
0x01 = No tamper/Case closed/EOL intact

Github pages, fast free static sites on github.

2017-05-05T11:45:00.002-04:00

GitHub pages, fast, free, static sites on GitHub.

Looks like it has been almost a year since I blogged anything here. I have a bunch of stuff I wanted to write about but haven't gotten around to it.

On a related note, I've started playing with github pages. These aren't easy to explain if you aren't coming from the right place. It could probably be said this is of most interest to developers. However these are probably of most interest to anyone who likes to use some flavor of markdown to quickly and easily edit text.

GitHub's documentation pages for this are a bit scattered. They don't really get to the point. Hopefully this won't sound like an ad.

GitHub Pages - What they are

A free, static, web site for yourself at username.github.io
A free, static, web site for your project at username.github.io/reponame

You get one site per github.com repo that is part of you repo, either in the docs directory or as a separate branch, gh-pages.

Easy - That is if you like to use some flavor of markdown to edit text files instead of dealing with HTML. You aren't restricted to plain text, or just markdown, you can stick html or other into you repo.
A templated site with prebuilt templates for a consistent look and feel. GitHub use Jekyll, a static web site generation tool, to turn your text files and the template you select into a web site. Jekyll runs on on GitHub's servers to build your site after you commit changes.
A site with no setup and no tools required - You can do everything from the github.com web interface. Nothing else is required. Of course, you can still work on your local machine with your choice of tools, since your web site is just another git repo, or part of your existing git repo.
A "development environment" for your site, also no setup required. Your site is a just a git repo hosted on github with all the things that come with it, revision control, rollbacks, change tracking, issue tracking, etc.

GitHub Pages - What they aren't:

A full web hosting account where you can run code to dynamically create pages, host a database, have email accounts, etc.
A tool to be used by someone that isn't comfortable with the basic concepts of:

source code control
markdown
what happens at "build time" vs. "run time".

likely to get broken into - your pages are a static site generated at "build time", so there is very little "attack surface" to be exploited.

What can I do with a static site?

This is something you either wrap your mind around or you don't. There is plenty you can do with a static site that doesn't run any code. There is also plenty you can't do with it. If you want WordPress, or a CMS, or some other app, get a web hosting account, try AWS, OpenShift, Google Compute Platform etc. However I've seen a lot of "dynamic" sites that didn't need to be dynamic.

There is quite a bit that you can do at site build time. There is also quite a bit that can be done but having processes that generate content that goes into your repo for displaying on your static site.

AMBE Exposed, by Bruce Perens K6BP

2016-05-23T15:22:00.000-04:00

While looking into something else, I stumbled upon the slides from Bruce Perens' presentation, AMBE Exposed This is from a TAPR/DCC talk in the fall of 2014. I'm not sure how I missed it at the time.

There is also a video of the talk which I haven't watched yet, on YouTube.

If you are interested in the problem of the patent encumbered CODECs that are used in DMR/MotoTRBO, APCO P25, D-STAR, and Yaesu System Fusion that keep developers from delivering the capabilities we'd like in our radio software/firmware, give this a read.

The presentation is 57 slides and chock full of background information.I'm going to keep this filed for when questions come up about why we can't do this or that without buying a dongle or using some limited software from anonymous authors.

This comes up over and over. Why doesn't my SDR, scanner, radio do DMR/MotoTRBO, D-Star, P25, etc. Recently this has come up again now that Uniden announced a DMR upgrade (for a fee) to their newest scanners the BCD-436HP and BCD-536HP. These radios already do P25 Phase 1 and 2, but there is a fee for the DMR upgrade to cover both the development costs and of course additional licensing fees to DVSI.

This will probably be of most interest to those that are familiar with and interested in open source.

There are also some good points about innovation usually coming from the upstarts and not the old guard.

First Screenshots with SpectrumSpy + Airspy

2016-05-20T14:51:00.002-04:00

Below are some screenshots from my first tests with the new SpectrumSpy application for the Airspy. I have the original AirSpy, not sure if it's considered the R0 or R1. The scan speed is pretty fast. It is certainly a very capable spectrum analyzer. My quick tests show lots of possibilities. My hopes for the future:

SpectrumSpy gets integrated with SDR# (SDRsharp), allowing some ability to click into a signal from a broad scan.
SpectrumSpy gets a plug-in architecture that will allow other developers to create new applications.
Someone writes a Uniden Close Call equivalent, that can quickly pick out nearby signals (those that appear with a threshold (18 db?) above the adjacent noise floor. (I need to check, I think Uniden's Close Call is 18 dB.
Ability to get data out of SpectrumSpy similar to rtl_power and rtl_power_fftw

The pictures. These really need to be seen at full screen to be appreciated. These are full screen from a 1920 x 1200 (16:10) monitor.

The first image is showing the full range of the R820T tuner in the Airspy from 25 Mhz up to around 1,900 Mhz. The top shows the spectrum view as you'd expect to see on an analyzer. The waterfall on the bottom is showing roughly 10 minutes of accumlated data.

Note: This is in a somewhat quiet RF environment. In other words, Not NYC! For test purposes I'm using a small hand-held whip antenna, about 6-8 inch. The gain is set pretty low.

One of the things I was looking for was how much background noise I have, and on what parts of the spectrum. Looks like there is are a couple of areas with some noise (520 mhz), 260-280 mhz, ...

Next are some screenshots that "zoom in", by reducing the scan range from the full scale using the choices from the menu, which are currently fixed. These might be editable in the XML config, but I didn't get there yet.

Next up, 1 Ghz. starting from 25 Mhz. so that means centered on 525 Mhz:

Thing to note:

The waterfall shows approximately 5 minutes of data. The full bandwidth scan waterfall had nearly double that. The only factor I changed was the amount scanned. A 1 ghz scan completes in half the time of the full bandwidth approx 1.9 ghz scan.
FM Broadcast between 88 Mhz and 2018 Mhz is easier to pick out.
Problem areas where I'm picking up noise are more apparent.
The noise at 520 Mhz isn't as constant as it looked.
The wide scale changes in the waterfall are due to me holding the AirSpy. There are some shielding problems I need to look into. The AirSpy R2 has some fixes that my original AirSpy does not.

Now lets look at a 500 Mhz scan:

Things to note:

Showing 500 Mhz, from 25 Mhz - 525 Mhz
Note the noise that is generating evenly spaced lines in the 100 - 175 Mhz range. This is something I'll need to track down.
One of the strong/constant signals that is visible is NOAA weather radio from Riverhead around 162 Mhz.
I'm occasionally receiving air band transmissions around 120 Mhz.
Around 440 - 450 Mhz, I'm either seeing a signal with an image, or I could be seeing repeater activity, on both the input and output frequencies.

Next step down in the menu is for a 200 Mhz scan:

Things to note:

200 Mhz, from 25 Mhz to 225 Mhz, (centered on 125 Mhz)
waterfall now shows about 2 minutes, since the scan rate has more than doubled by going from 500 mhz to 200 mhz.
The noise may start around 48 Mhz, and with harmonics/images roughly every 5-6 mhz.

Next, 100 Mhz scan:

Notes:

Range 25 Mhz - 125 Mhz.
Waterfall is covering 1.5 to 2 minutes, so scanning 100 mhz is happening pretty quickly.
Main feature is the FM Broadcast band, 88 - 108 Mhz.
Air band traffic visible around 123 Mhz.

Next, 50 Mhz:

Notes:

25 - 75 Mhz covered
waterfall now covers only about 1 minute.

Next, 20 Mhz, showing the FM Broadcast band:

Notes:

88 - 108 Mhz. centered on 98 Mhz.
It's easy to tell which are the strong FM stations in my area.

Lots more to play with. I have a SpyVerter up converter which will let me do < 30 Mhz, but it wasn't very interesting with only a short hand-held whip. Hopefully I'll have a chance with a random wire soon.

Please let me know what you'd like to see and any observations you have on these spectrum scans in the comments.

EDIT:

So, I'm happy that I'm able to upload these images to blogspot at full resolution. I need to figure out how to get blogspot to allow clickable thumbnail/full res. images. I'm going to try this over on Wordpress.com. I haven't done much with WordPress, but need to get some experience for a work project.

See the WordPress version of this point. Nicer looking but still no click to full-res version.

Structure of Tytera MD-380 .test radio calibration settings file.

2016-02-13T16:15:00.002-05:00

Continuing from my previous post, Reading and Backing up Tytera MD-380 calibration settings, here are some notes on the structure of the saved .test file. I'm trying to decode the layout using hexdump -C.

First here are the screen shot of the data for reference:

Now here is the hexdump -C output.

00000000  0a 96 89 ad 4b 82 7b ff  62 68 6e ff ff ff ff ff  |....K.{.bhn.....|
00000010  91 92 93 90 8d 8d 8d 8f  91 ff ff ff ff ff ff ff  |................|
00000020  4d 4d 4d 4b 49 45 41 41  42 ff ff ff ff ff ff ff  |MMMKIEAAB.......|
00000030  5e 74 8b 9c ae bf d0 dd  ea ff ff ff ff ff ff ff  |^t..............|
00000040  1c 1a 19 19 19 19 19 19  1a ff ff ff ff ff ff ff  |................|
00000050  2d 2a 28 27 27 2c 31 2d  2a ff ff ff ff ff ff ff  |-*('',1-*.......|
00000060  35 32 2f 2c 2a 2b 2c 2c  2c ff ff ff ff ff ff ff  |52/,*+,,,.......|
00000070  36 34 33 2f 2c 31 36 33  31 ff ff ff ff ff ff ff  |643/,1631.......|
00000080  03 03 04 04 04 04 04 04  04 ff ff ff ff ff ff ff  |................|
00000090  25 24 23 22 22 21 20 1f  1f ff ff ff ff ff ff ff  |%$#""! .........|
000000a0  2b 2a 2a 28 27 26 26 25  24 ff ff ff ff ff ff ff  |+**('&&%$.......|
000000b0  37 36 36 35 35 34 33 31  2f ff ff ff ff ff ff ff  |76655431/.......|
000000c0  64 64 64 64 64 64 64 64  64 ff ff ff ff ff ff ff  |ddddddddd.......|
000000d0  1f 1d 1c 1c 1d 1c 1c 1c  1c ff ff ff ff ff ff ff  |................|
000000e0  80 80 80 80 80 80 80 80  80 ff ff ff ff ff ff ff  |................|
000000f0  1e 1e 1e 1e 1e 1e 1e 1e  1e ff ff ff ff ff ff ff  |................|
00000100  00 00 00 00 00 00 00 00  00 ff ff ff ff ff ff ff  |................|
*
00000130  33 2f 2c 29 27 25 23 20  1d ff ff ff ff ff ff ff  |3/,)'%# ........|
00000140  5f 5c 5a 58 56 54 52 51  50 ff ff ff ff ff ff ff  |_\ZXVTRQP.......|
00000150  00 00 00 00 00 00 00 00  00 ff ff ff ff ff ff ff  |................|
*
00000170  32 32 32 32 32 28 1e 1e  1e ff ff ff ff ff ff ff  |22222(..........|
00000180  7f 7d 7b 79 77 70 6a 6b  6d ff ff ff ff ff ff ff  |.}{ywpjkm.......|
00000190  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000001b0  00 35 10 40 00 45 10 40  00 35 10 41 00 45 10 41  |.5.@.E.@.5.A.E.A|
000001c0  00 35 10 42 00 45 10 42  00 35 10 43 00 45 10 43  |.5.B.E.B.5.C.E.C|
000001d0  00 35 10 44 00 45 10 44  00 35 10 45 00 45 10 45  |.5.D.E.D.5.E.E.E|
000001e0  00 35 10 46 00 45 10 46  00 35 10 47 00 45 10 47  |.5.F.E.F.5.G.E.G|
000001f0  00 95 99 47 00 50 99 47  00 00 00 00 00 00 00 00  |...G.P.G........|
00000200  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
00002000

So MD-380.exe, writes out 8 KB, but it looks like only 512 bytes are actually used. the bytes from 512-8192 are all set to 0xFF.

First thing that is easy to spot by eye, the row labeled "Mod1 Partial is all 128 (decimal) which is 0x80 in hex. A row of '80 80 80' appears at the line with the address 0xE0 (224 bytes into the file).

There are 9 columns in the GUI and it is easy to see that most of the rows of 16 bytes have 9 values and 7 bytes of 0xFF. So that's a nice convenient 16 byte per row layout in the file.

Moving up in the screen shot, the first row with data in all columns is "Tx Hight Power" with values of 145, 146, 147, 144 which is hex 91, 92, 93, 90. This is easy to spot in the second row of the hexdump.

So there are only 16 bytes before that. The GUI shows 13 rows before that, but the 11 rows VOX1, VOX10, ..., Freq. Adjust (Low), only have values in one column. So next step is to locate these values, which are 10, 150, 137, 173, (hex 0a, 96, 89, ad). Those as easily spotted as the first bytes of the file starting at offset 0. There are 11 bytes there that aren't 0xFF.

OK so far we know:

Rows 2-13 (VOX 1, ... Freq. Adjust Low) are stored in the first 11 bytes 0x00 - 0x0a.
Rows 14-39(?) are stored from bytes 0x10 - 0x18F, as 16 bytes per row using only the first 9 bytes for each calibration value.

That leaves the frequencies that are listed in the first two rows 'Rx Freq' and 'Tx Freq'. It looks like these are encoded as 4 bytes in the 72 bytes located at 0x1b0 - 0x1f7.

It should be pretty easy to map this into Chirp's bitwise definition.

Hopefully this will be of use to some.
--Rob

Read and Backup Tytera MD-380 calibration settings.

2016-02-13T16:04:00.001-05:00

On the Tytera MD-380 Yahoo Group, Stan G4EGH, posted that there is a hidden 'Test Mode' in the MD-380 CPS programming software. in this case 'test mode' is used for reading and writing the radio's calibration settings that are usually done at the factory, but might be changed by someone with a DMR-capable service monitor in the field when recalibrating the radio. (This 'test mode' shouldn't be confused with any sort of debug mode.).

The important part about this find is that every radio has calibration settings that are specific to it. Think of it as a tuning/fine-tuning step that is done after manufacturing in order to make sure the radio is performing optimally. This step is necessary because the electronic components all have some tolerance (10%, 5%, 1%) for how close they come to their specified value.

Making a backup of your radio's calibration settings is a good idea. The settings are written into flash memory or EEPROM and could become corrupted or lost. If you don't know what the settings are, and don't have the proper test equipment you might have to send the radio in to be recalibrated.

The procedure to make a backup of your Tytera MD-380's calibration data using Tytera's MD-380 CPS v1.30 programming software is:

Close the MD-380 software if you have it open.
Find the setting.ini file. On a default install, for Windows 7 (64 bit), the file location is C:\Program Files (x86)\MD_380\MD_380\SoftWare_EN\setting.ini
Edit the settings.ini file with a text editor like Notepad.
Locate the line testmode=0 in the [setup] section. Change the value to 1. Save the file.
Start MD-380.exe. Starting it through the normal menu/shortcut is fine.
Connect the radio with the USB cable and turn it on.
Hit CTRL-T, to read the data from the radio.
Click "Save Test Data" which will save a .test file with an 8 KB binary of the calibration data.
Put the .test file some place safe where you will be able to find it again when you need it.

Here's are two screen shots from my radio. Unfortunately, I couldn't resize the window to make it all fit:

I've opened an issue in Travis Goodspeed's md380tools github repo to track progress of adding this capability to md380tools.

Hope this helps somebody.

Hacking the Z-Wave Protocol with a Hack-RF

2016-01-20T16:11:00.001-05:00

More cool stuff for home automation and hacking:

I've been doing a lot with using rtl_433 and an rtl-sdr to receive temperature and humidity sensors, outdoor weather stations, and security system sensors (aka contacts).

So, I've been wondering about receiving and decoding home automation RF protocols like Z-Wave, Insteon, Zigbee which aren't terribly open. The other day I saw this article on the RTL-SDR.com blog, "Hacking the Z-Wave Protocol with a Hack-RF", about a Shmoocon talk. Exactly what I've been waiting for. I have a HackRF in that I haven't been doing much with ... yet.

I assumed it would be possible to receive Z-Wave with an RTL-SDR. There are a number of USB Z-Wave sticks that are starting to get popular. Many home automation controllers that have one of the protocols implemented are fairly expensive and somewhat closed.

So I'm excited to see this, quoting the RTL-SDR.com post

Z-wave is a wireless protocol that is used often in applications like smart home and industrial automation. It essentially allows various wireless nodes to connect and talk to one another within your house, using 900 MHz wireless technology. Some common examples of Z-wave node products might be wireless controlled lights, door locks, thermostats and other security devices like motion detectors.

Recently at Shmoocon 2016 (a yearly hacking and security themed conference), presenters Joseph Hall and Ben Ramsey showed how they were able to use a HackRF software defined radio and some GNU Radio based software to not only sniff Z-wave packets, but to also control Z-wave devices. What’s also interesting is that they found that encryption on z-wave devices was rarely enabled, except for five out of nine door locks that they tested where it was enabled by default.

See the full story at Hackaday and have a look at their code on GitHub.

Unfortunately it looks like their stuff requires two HackRFs, one for transmitting and one for receiving. I unfortunately, only have one HackRF. There has been some work to enable better T/R (Transmit/Receive) switching into the HackRF libraries. I've seen the commits go by but haven't looked into them much yet.

Things are getting interesting, stay tuned for more...

Links:

RTL-SDR.com - "Hacking the Z-Wave Protocol with a Hack-RF"
Hack-a-day Story
GitHub Repo.

Reverse Engineering Cheap Chinese Radio Firmware TyTera MD-380 (Shmoocon 2016 via Hackaday)

2016-01-20T14:45:00.002-05:00

Cool Stuff:

For those who are interested in the intersection of microcontrollers, hacking, and radio, an interesting deep dive into the firmware of one of the Chinese DMR/mototrbo ($140) radios, the Tytera MD380.

Unlike the cheap analog Chinese radios (Wouxun, Baofeng) which can only be programmed once, this radio supports a firmware upgrade. The bit that is interesting for people who aren't deep into digital electronics is that this hack produced a version of the firmware that turns the MD380 into the first (hardware) DMR scanner. N2NOV has been pointing out the gap, that no scanners cover DMR for a while now.

Note: this exploration/hack is at the experimental stage, so I wouldn't consider this ready/usable/applicable to anyone but those that want to experiment and are willing to risk bricking their radio or worse.

I couldn't resist, so I ordered a Tytera MD-380 this morning. More details to come. So now my To Do list includes, learning about DMR/MotoTRBO, programming NYC area DMR amateur radio repeaters, and finding/joining communities that are covering alternative firmware development for the MD-380.

Out of the box, this radio is supposed to allow field programming (aka front panel programming) of DMR talkgroups.

Travis GoodSpeed's github repo, has a package of command-line Python tools for the MD380. Looks like enough for reading and writing the radio on Linux and Mac OS. Also there is the beginnings of a CHiRP driver for the MD380. It doesn't read/write the radio but can be used for maintaining the analog channels and banks.

Also, hack-a-day, has had some good radio articles lately that aren't that deep into digital electronics for a wider audience.

You might recognize the name Travis Goodspeed from other projects like the GoodFET, an open source JTAG adapter inspired by Dangerous Prototype's Bus Pirate.

Links:

Hack-a-day article: Reverse Engineering Cheap Chinese Radio Firmware from Shmoocon 2016
Hack-a-day articles in category Radio-Hacks

(There is also a tag for Radio)

PoC || GTFO Newletter with the referenced article,the article is on pages 76-87.
Amateur Radio Guide to DMR (Digital Mobile Radio) - 28 page PDF introduction by W2XAB
The DMR-MARC worldwide network - good web site with information about amateur DMR repeaters, and talkgroup listings
Travis GoodSpeed's github repo
Travis Goodspeed's blogspot blog, (last update July 2013)

More Yaesu VX-8 GPS implementation details.

2016-01-15T13:22:00.000-05:00

4Z7DTF left a comment on my post "Another Yaesu VX-8DR external GPS with an Arduino/..." to let me know about his VX-8 Arduino GPS project on github.

There have been a number of projects that use either an Arduino or bare ATtmega microcontroller to turn the GPS module's NMEA sentences back into the a format the brain dead parser built into the VX-8's firmware can handle.

He has done some additional testing, actually fuzzing, showing the VX-8's parser does no error checking what so ever.

Also, another interesting bit, in his work, he noted there is no need for the communication to be bi-directional. I don't know what, if anything the VX-8 tries to send to the GPS module, but it appears to be unnecessary.

What is interesting about that is the microcontroller then really only needs a single serial port. Most of the other projects are bi-directional using a software UART emulation for the second port. So it might be possible to implement this project with something much smaller and even lower power. It would be interesting to see if this can be done with the ATTiny85, using something like the Adafruit 3.3V trinket. That is supposed to draw around 9 milliAmps at 8 Mhz, but 3 mA of that is just for the green power LED! The ATTiny has no built in UART, so it would be all software serial.

Raspberry Pi (RPi) and Amateur Radio Resources

2016-01-14T17:40:00.002-05:00

Here are a few resources you might find helpful for Linux and radio on PCs or RPis.

http://www.trinityos.com/HAM/index-ham.html

Ham radio software on CentOS Linux
Getting Started with Packet Radio
Raspberry Pi APRS and Packet Radio
APRS beginner's guide
Amateur Radio and Linux: Opening Doors without Windows

Raspberry Pi for Ham Radio Yahoo Group - a fairly active Yahoo Group. Yahoo Group Description:

This is a place for Amateur Radio Ops to discuss the Raspberry Pi and how it can be applied to Ham Radio. This is a moderated Group. Please keep posts civil and on topic. (Any discussion of the RPi is welcome)

https://groups.yahoo.com/neo/groups/Raspberry_Pi_4-Ham_RADIO/info

Info on Intel's AMT with an open source client.

2016-01-14T17:26:00.000-05:00

Found this blog entry, "Everything you need to know about Intel AMT and the Intel NUC with Ubuntu" on Dustin Kirkland's blog. AMT is vaguely related to IPMI, but is somewhat Intel proprietary. The key bit of info is there is a package available for Ubuntu, amtterm, that has a command, amttool that can be used for remote management of systems with AMT built-in (Intel VPro) and enabled.

Automate Cygwin package installation, search for packages from the command line, grep the list of installed packges.

2016-01-14T17:13:00.000-05:00

Stumbled across two things for improving life when dealing with Cygwin. (Cygwin is a port of Unix-like GNU tools for Windows.)

First, the standard Cygwin-setup utility takes command line arguments that will avoid all of the prompts, so you can have a single command to update a system without having to do a lot of clicking. See this blog post from Cody Dunne.

Put this in a batch file, run it as administrator:

cd C:\cygwin
wget -N http://cygwin.com/setup-x86.exe
setup-x86.exe --no-desktop --no-shortcuts --no-startmenu --quiet-mode

Or if you are typing it by hand:

setup-x86 -nNdq

Second, there is a nice command link apt-get like utility, called apt-cyg. It's a neat, simple bash script. Nothing to really install. Provides command like search, and text access to the list of installed packages. apt-cyg is in Stephen Jungel's github repo.

Note: the key data is in the setup INI files stored in cygwin-pkgs/mirror-name/x86/setup.ini.

Hope this helps,
--Rob

Acurite 592TXR Temperature and Humidity Sensors now decoded by rtl_433.

2015-11-28T20:22:00.000-05:00

I've added decoding of Acurite's 592TXR "Tower" temperature and humidity sensors to rtl_433. These are small, inexpensive, wirelesss (433 Mhz), temperature and humidity sensors. The 592TXR has several different model numbers including 06002RM

These are compatible with Acurite's consoles such as the 01512 that I have as well as Acurite's Acu-Link Internet bridge which posts to acu-link's web page as well as weatherunderground. I picked up the Acurite 5-n-1 Weather Station, a console, and the internet bridge because the support for the 5-n-1 had been added to rtl_433 and the package price was pretty reasonable.

There were a number of people interested in decoding the 592TXR, but for some reason, it never got added, so I finally added it and cleaned up the Acurite 5-n-1 weather station decoding. The pull request got merged November 8th, 2015.

I think the temperature only version, the 592TX, should also be supported but I don't have one to test. Please let me know if it decodes successfully or not.

The protocol used by the Acurite 592TXR and the 5-n-1 weather station are very similar. The weather station's messages are one byte longer, but they are basically the same with the same RF signaling characteristics.

Remotely monitor Refrigerator / Freezer temperature with Acurite 986 and rtl_433 (rtl-sdr)

2015-11-28T19:45:00.000-05:00

I suspected the thermostat in my basement refrigerator was going bad, so I picked up an Acurite 986 refrigerator and freezer remote thermometer. The display unit will give alarms if the temperature goes out of range.

I wanted a better picture of what was going on so I figured out the Acurite's 433 mhz protocol for the 986 sensors. I've added support to rtl_433. The pull request was merged November 20th, 2015.

Now I pump the data into rrdtool and see what's going on. I now see how long and often the compressor is running, and how long it times to warm up between cycles. The spikes are the defrost cycles.

Now I can also monitor/get alerted when I'm out of the house.

I'm pretty happy with the Acurite 986 display and temperature sensors even without the rtl_433 decoding.

Acurite 00986 Refrigerator / Freezer Thermometer Protocol

Includes two sensors and a display, labeled 1 and 2, by default Sensor 1 - Refrigerator, 2 - Freezer.
Data format: Pulse Position Modulated (PPM), 5 bytes, sent twice, no gap between repeaters
Start/sync pulses: two short, with short gaps, followed by 4 long pulse/gaps.
Data Format - 5 bytes, sent LSB first, reversed
TT II II SS CC
TT - Temperature in Fahrenehit

integer,
MSB = sign. Encoding is "Sign and magnitude"

II - 16 bit sensor ID changes at each power up
SS - status/sensor type

0x01 = Sensor 2 (
0x02 = low battery

CC = CRC (CRC-8 polynomial 0x07, little-endian)

I was able to easily figure out the CRC with CRC RevEng..

Another Yaesu VX-8DR external GPS with an Arduino/ATmega328 translator.

2015-08-14T09:25:00.001-04:00

I've collected links for a few of these projects to add a better external GPS to the Yaesu VX-8DR, instead of the somewhat proprietary Yaesu option.

Here's another one from VK3YY that got posted recently:

https://vk3yy.wordpress.com/2015/07/24/vx-8dr-and-gps/

Here's code from DFannin on github:

Arduino code for buidling Yaesu VX8r Handheld Transmitter-compatible GPS

Update 2016-01-15, 4Z7DTF notified me about his project, which includes more additional analysis of how poor the VX-8's parsing and error handling is.

4Z7DTF's VX-8 Arduino GPS interface on github

Background Info:

Good detailed blog post Reverse Engineering the Yaesu VX-8DR GPS Interface. From Feb. 2013. He didn't arrive at the solution, which I believe F4FXL and at least one other have. But I think he's got most of the relevant details for the padding differences listed as well as some other very useful info including details on the GPS chips used in VX-8 and VX-8G.

We now know how to connect to and send a properly formatted GPS NMEA message to the Yaesu VX-8DR. Here's the summary:

9600baud TTL 3.3V serial signalling, 8/N/1
- NOT RS232 -5 to +5V signalling -- you need a level converter if that's all you have
3-wire physical interface to the following pins:

Pin GPS Side Purpose Yaesu Side Purpose

4 GPS RX Yaesu TX

5 GPS TX Yaesu RX

6 GPS GND Yaesu GND
According to 4Z7DTF (2016-01-15), there is no need for the communication to be bidirectional. Only the TX Data from the GPS to the VX-8 is required.

Pin	GPS Side Purpose	Yaesu Side Purpose
4	GPS RX	Yaesu TX
5	GPS TX	Yaesu RX
6	GPS GND	Yaesu GND

The messages need to be formatted exactly as follows:

Message Type	Source	Sentence
$GPGGA	Sample	`$GPGGA,123223.000,4131.2334,N,00021.1216,E,1,04,02.7,00123.4,M,0051.7,M,000.0,0000*41`
	Syntax	`$GPGGA,hhmmss.sss,llll.llll,a,yyyyy.yyyy,a,x,xx,xx.x,xxxxx.x,M,xxxx.x,M,xxx.x,xxxx*hh`
$GPRMC	Sample	`$GPRMC,123223.000,A,4131.2334,N,00021.1216,E,0000.00,291.33,301011,,*3E`
	Syntax	`$GPRMC,hhmmss.sss,A,llll.llll,a,yyyyy.yyyy,a,xxxx.xx,xxx.xx,xxxxxx,,*hh`
$GPZDA	Sample	`$GPZDA,123223.000,30,10,2011,,*55`
	Syntax	`$GPZDA,hhmmss.sss,xx,xx,xxxx,,*hh`

rtl_433 now decodes DSC 433 Mhz wireless securty contacts

2015-08-06T15:07:00.001-04:00

** UPDATE For status bit decoding see rtl_433 DSC Status Bit Decoding **

If you have a DSC (Digital Security Controls) home security system, with wireless sensors such as door / window contacts, glass break detectors, smoke, CO2, heat, and water detectors, you can now monitor them with rtl_433. The code is now in the mainline Merbanan github repo.

Only the 433 Mhz security sensors/contacts devices are currently supported. I will be working on other devices soon. I have almost all of the status bits worked out. I will be submitting a pull request soon.

DSC alarm systems are also sold under other brands such as ADT Pulse, and a number of cable/telephone company's home automation systems, such as Time Warner Intelligent Home. DSC is a division of Tyco, so you will also see DSC products listed as Tyco Security, though Tyco has a whole list of security brands.

These are fairly inexpensive wireless devices that can also be useful for a variety of home automation projects.

The DSC WS4945 - Wireless Door and Window contact can be used as a magnetic contact or used with any sort of sensor that provides a normally closed output. If you are using it for home automation without a security system, it doesn't matter if it is normally closed or normally open. It will transmit at any state change. The device also sends a heartbeat with the current state every 64 minutes.

The Vanishing door/window contact, EV-DW4975 is quite thin and small if you don't need the screw terminals for wiring up some other type of sensor. It will barely be noticed on most doors and windows.

If you are interested in decoding DSC's wireless protocols, or have any information to share, please contact me, I could certainly use someone to collaborate with.

** UPDATE For status bit decoding see rtl_433 DSC Status Bit Decoding **

Popular Electronics Magazine archive online 1954 - 2003

2015-08-06T14:45:00.002-04:00

A piece of electronics history:

Popular Electronics Magazine issues from 1954-2003 are available on line.

Might be old news, but I just saw this circulating on a few mailing lists.

This is the first time I recall seeing a reference to this web site, American Radio History.

http://www.americanradiohistory.com/Popular-Electronics-Guide.htm

Popular Electronics was created in 1954 by Ziff-Davis Publishing for an audience of electronics hobbyists and experimenters. It soon became the "World's Largest-Selling Electronics Magazine". The circulation was 240,000 by 1957 and exceeded 400,000 by 1963. Rival Electronics World was merged into Popular Electronics in 1972.

Popular Electronics became Computers & Electronics in November 1982; and then ceased publication in April of 1985.

The title returned in February 1989 under the ownership of Gernsback Publications which purchased the name and gave it to their Hands-On Electronics magazine. Popular Electronics ceased publication in December of 1999, returning as Poptronics in January of 2000 after merging with Electronics Now. The final issue was January, 2003.

Enjoy.

New Toys: Getting Deeper into Software Defined Radio (SDR) (AirSpy and HackRF Blue)

2015-04-17T16:41:00.000-04:00

This is mostly a tease / place holder. Around Christmas time I decided to get deeper into Software Defined Radio (SDR). So I ordered an Airspy and a Hack RF Blue. So far, I've received the AirSpy and am enjoying it very much. The Hack RF Blue should hopefully be here soon.

Previously I've been using the $15-20 RTL-SDR dongles. These are very cheap and useful, but plagued with lots of noise, frequency inaccuracies and other problems. Still they are a great way to get started and start learning.

The AirSpy is a world of difference from the RTL-SDR dongles. One of the reasons that I bought it was a number of people who seemed to have deep RF engineering backgrounds seemed to be pretty excited about it. There are many good reviews available.

I ordered the HackRF Blue to experiment with GNU Radio and especially try some of the transmission capabilities for digital RF hacking. Initially I'll probably be doing further experiments with simple 433 Mhz devices.

I expect based on receivers that the HackRF's receiver will not be as good as the AirSpy's by a good margin, for sensitivity, selectivity, etc.. However, the HackRF is capable of operating on a much wider frequency range (10 Mhz - 6 Ghz) than the R820T (24 Mhz - 1.8 Ghz) tuner chip inside the AirSpy.

More to come.

Your Radio's Reverse button / Quickiy Checking the Repeater's Input Frequency

2015-04-17T16:27:00.002-04:00

[This was originally published on a mailing list, but seemed worth making more widely available.]

Some amateur radios have a "Reverse"(*) button that swaps the repeater input and output frequencies, allowing you to quickly monitor the repeater input and transmit on the repeater output. When I first started out, I didn't realize the value of this.

The benefits of this feature are:

You can quickly listen to the repeater input to determine if someone transmitting is close enough for you to use simplex and free up the repeater.
If the repeater isn't working, you can get anyone who is monitoring the repeater's output and is within simplex range, to hear you by transmitting on the repeater's output.
During time of malicious interference or other search operation, if we all switch over to monitoring the input and make note of whether we can hear the transmitting station, we can use the information to figure out roughly what area the transmitting station is in.

And finally, the benefit that is relevant to the original topic, hitting the reverse button on many radios is a quick way of seeing what frequency your radio is programmed to transmit on for a repeater. Your radio display will need to be in a mode to show the frequency rather than the label.

Check your radio's manual to find out how to activate the reverse feature as the button might have an obscure label. A few common one:

Wouxun - It's the scan button. (A quick press and release).
Baofeng UV-5 - The * button. (A quick press and release).
Many Yaesus - Home/Reverse, HM/RV, Rev, etc.

RTL-SDR Buying Tips

2015-04-17T16:21:00.002-04:00

[This was originally posted to a mailing list.]

First, a good starting point on RTL-SDR is the blog site www.rtl-sdr.com.

(I've mentioned it here before and forwarded some relevant posts about things you can do with an SDR such as the RTL-SDR.)

The RTL-SDRs are almost all the same chinese, ultra cheaply made receivers in the range of $15-25. It isn't so much about which device is trustworthy, it's what tuner chip does it have.

At this point, I suggest getting one with the R820T2 tuner which is newer, seems to perform a little bit better, but costs around $5 more than the others. IF you get an R820T (not T2) that will do fine as well.

Places that "specialize" in RTL-SDR and aren't too overpriced are:

Nooelec, http://www.nooelec.com/store/, They also sell through Amazon.

Their "NESDR Mini 2 SDR" was mentioned on the net $25. It has the R820T2 tuner chip. It's not clear if they upgraded any of the other components other than the included mini-whip antenna which you will probably replace.

http://www.nooelec.com/store/sdr/nesdr-mini2-rtl2832u-r820t2.html
RTL-SDR.com is also selling their own branded R820T2 usb dongles. They also sell through Amazon. They claim upgraded components and a better oscillator (though not temperature controlled) than the usual ones which can easily have a -75 to +75 PPM error.

At this point, almost all of the devices come with an MCX connector so you will need an MCX adapter to hook it up to a real antenna. Both NooElec and RTL-SDR.com's amazon store have MCX adapters.

Also if you don't have any, get some USB extension cables (A male to A-female) around 10 ft in length. These devices have no shielding, so you want to get them as far away from your computer as you can while sticking within USB length limits.

Try to get a good quality USB extension cable with a ferrite core near the end to cut some of the noise. You might also want to buy some additional snap on ferrite cores.

Note: The frequency range on these is about 24 Mhz - 1,700 Mhz so you won't be able to do any HF with the exception of 10 meters and maybe 12 meters. An upconverter can be used if you want to receive HF.

If you connect the RTL-SDR to an outdoor antenna, keep in mind that almost all of these devices have no viable ESD protection.

NBEMS, Radios and Digital Modes: Getting the Message.

2015-04-17T16:16:00.001-04:00

Here's a screen shot from a recent Thursday night digital radio net that might help give you an idea of what it is all about if you haven't tried it.

The screen shot shows a received radiogram form as it would look on paper displayed on an Android tablet or phone.

Note: The only equipment used to receive this was an handheld radio (HT) and an Android Tablet. No cable, or interface, was used between the tablet and the HT. The tablet's microphone decoded the audio coming out of the HT's speaker.

The app on the tablet is AndFlMsg which is a free Android application that implements a some parts of what's available in the FLdigi suites.

While in this case, the information for the form could have been relayed by voice, it could have easily been a picture, spreadsheet, or other file that would be difficult or impossible to relay by voice if the only available infrastructure was a radio.

Standard Container Manifesto

2015-04-17T16:08:00.001-04:00

If you haven't seen it, see the "Standard Container Manifesto" below. It might help you understand some of the current buzz around container technology. This one was added to the Docker README at one point but has been since removed. There are better but longer descriptions.

Note: to appreciate this, it helps to have been involved in the struggles of delivering enterprise IT where one of the core challenges, (if not the fundamental problem), is trying to get away from everything being somewhat different because it's all built by hand.

Oh, and if you aren't familiar with the story of the standard shipping container and its impact on global commerce, this looks like a reasonable overview: http://www.nytimes.com/2006/03/23/business/23scene.html?_r=0

1. STANDARD OPERATIONS

Just like shipping containers, Standard Containers define a set of STANDARD OPERATIONS. Shipping containers can be lifted, stacked, locked, loaded, unloaded and labelled. Similarly, standard containers can be started, stopped, copied, snapshotted, downloaded, uploaded and tagged.

2. CONTENT-AGNOSTIC

Just like shipping containers, Standard Containers are CONTENT-AGNOSTIC: all standard operations have the same effect regardless of the contents. A shipping container will be stacked in exactly the same way whether it contains Vietnamese powder coffee or spare Maserati parts. Similarly, Standard Containers are started or uploaded in the same way whether they contain a postgres database, a php application with its dependencies and application server, or Java build artifacts.

3. INFRASTRUCTURE-AGNOSTIC

Both types of containers are INFRASTRUCTURE-AGNOSTIC: they can be transported to thousands of facilities around the world, and manipulated by a wide variety of equipment. A shipping container can be packed in a factory in Ukraine, transported by truck to the nearest routing center, stacked onto a train, loaded into a German boat by an Australian-built crane, stored in a warehouse at a US facility, etc. Similarly, a standard container can be bundled on my laptop, uploaded to S3, downloaded, run and snapshotted by a build server at Equinix in Virginia, uploaded to 10 staging servers in a home-made Openstack cluster, then sent to 30 production instances across 3 EC2 regions.

4. DESIGNED FOR AUTOMATION

Because they offer the same standard operations regardless of content and infrastructure, Standard Containers, just like their physical counterpart, are extremely well-suited for automation. In fact, you could say automation is their secret weapon.
Many things that once required time-consuming and error-prone human effort can now be programmed. Before shipping containers, a bag of powder coffee was hauled, dragged, dropped, rolled and stacked by 10 different people in 10 different locations by the time it reached its destination. 1 out of 50 disappeared. 1 out of 20 was damaged. The process was slow, inefficient and cost a fortune - and was entirely different depending on the facility and the type of goods.
Similarly, before Standard Containers, by the time a software component ran in production, it had been individually built, configured, bundled, documented, patched, vendored, templated, tweaked and instrumented by 10 different people on 10 different computers. Builds failed, libraries conflicted, mirrors crashed, post-it notes were lost, logs were misplaced, cluster updates were half-broken. The process was slow, inefficient and cost a fortune - and was entirely different depending on the language and infrastructure provider.

5. INDUSTRIAL-GRADE DELIVERY

There are 17 million shipping containers in existence, packed with every physical good imaginable. Every single one of them can be loaded on the same boats, by the same cranes, in the same facilities, and sent anywhere in the World with incredible efficiency. It is embarrassing to think that a 30 ton shipment of coffee can safely travel half-way across the World in less time than it takes a software team to deliver its code from one datacenter to another sitting 10 miles away.
With Standard Containers we can put an end to that embarrassment, by making INDUSTRIAL-GRADE DELIVERY of software a reality.

Better PC Sound Card Oscilloscope software (windows).

2015-01-17T19:12:00.001-05:00

TL;DR - Visual Analyzer, PC Sound Card Oscilloscope software. Nice spectrum analyzer. Worth checking out. http://www.sillanumsoft.org/prod01.htm

Through a really good YouTube Post on using an SDR for Frequency Deviation Measurement on FM transmitters I learned about Visual Analyzer. I should probably do a separate post just on this.

Previously I used Xoscope on Linux and Zeitnitz Soundcard Oscilloscope (http://www.zeitnitz.eu/scope_en).

I had also found, but not used Zelscope, Soundcard Oscilloscope and Spectrum Analyzer.

I originally got some pointers on sound card osclloscopes, from Virginia Tech's Introductory Electronics courses that were based on their Lab in a Box, so that students would have all of their own materials for doing the electronics work without having to be in a physical lab. See:

Virginia Tech, Experiment 12, Calibrating a Sound Card Oscilloscope

I only went so far with sound card oscilloscopes, because shortly after I started experimenting, the Rigol DS-1052E oscilloscope became available within my budget. I bought it for $400 direct from China. The Rigol caused a little bit of a revolution in terms of oscilloscope availability and pricing.

That was all back in 2009 and 2010 when I started reading a lot more about electronics. In December, 2009, I finally took the exams from my amateur radio license. I passed both Technician and General with 100% and went back for the Extra Class at the next exam session. I got one wrong on my Extra.

Of course, the interesting bit that got me here writing this today is that the RTL-SDR stick can be used as the analog (ok radio frequency) front end for a software oscilloscope, spectrum analyzer, deviation meter, etc. Especially for those of us without much in test equipment.

Intel Atom (Avoton) Mini-ITX (NAS) Server Build Notes

2015-01-12T14:21:00.000-05:00

I'm building a mini-ITX NAS style server using Intel's low-power Atom server chip, known as Avoton. The highlights are 8 cores, 64 GB max memory, yet passively cooled, quiet and low power, 20W TDP.The system's idle power usage without spinning disks is only 14 Watts. This makes it ideal for a SOHO file server, NAS server, lab box, etc.

The system I'm assembling resembles iXsystem's FreeNAS mini. The main difference is that I went with the Supermicro motherboard instead of the ASRock motherboard. I'll compare the two motherboards later and/or in a separate blog post. However, I'll summarize my decision as The ASRock is better if you are going for a pure storage (NAS) box. I went with the Supermicro as a better general purpose system with USB 3.0 ports and 4 x GbE ports.

Components:

Supermicro AISAi-2750F Motherboard
Supermicro Chassis and 250W Power supply 721TQ-250B
16 GB: 2 x 8 GB Crucial SO-DIMM with ECC

Case and Power Supply

One of the most difficult decisions was trying to find a good case and power supply. There is a lot of poorly designed cases. There aren't many reviews for mini-ITX NAS-style cases. Through the reviews that are available I found one good choice which is also the same case that iXsystems uses for the FreeNAS Mini, the Ablecom CS-M50. Unfortunately the Ablecom isn't sold in the US directly. It is primarily sold to OEMs in large quantities. I stumbled around for a while until a kind person clued me in that Supermicro sells the Ablecom CS-M50 as the Superchassis 721TQ-250B. It is even linked from the page for the A1SAi-2750F motherboard and I didn't notice it or assumed it would be yet another crap case.

The summary is the Ablecom CS-M50, aka Superchassis 721TQ-250B is a very nice case with real hot swap drive support. The most detailed reviews are actually for the FreeNAS Mini. You can also find some reviews searching for the Ablecom CS-M50.

The one problem so far is that the front panel USB ports are USB 2.0. The A1SAi motherboard has header connectors for USB 3.0, which use a different style header connector. Currently, I've got no front panel USB ports. I've emailed Supermicro support.

Other People's Builds

Here are some of the sources that I used in making my decisions:

My FreeNAS Build with The Supermicro A1SAi-i2750f (reddit, billakay)

Pictures on Imgur

/My FreeNAS Build with Supermicro A1SAi-2750F (FreeNAS Forum)

To Do

Determine what combination of hypervisors and operating system

Linux Host + VirtualBox
Linux Host + KVM
VMware ESXi
FreeNAS native FreeBSD

Solve Front Panel USB port connectivity problem:

Ideally there is a board from Ablecom, Supermicro or someone else that will give me USB 3.0 front panel ports.
Alternatively, an adapter cable that gives me USB 2.0 ports would be preferred.

Things I've Learned

The Supermicro 721TQ-250B case is the same as the Ablecom CS-M50 and is available at retail in the US.
The AST2400 IPMI BMC controller with fully integrated keyboard, video, and mouse, iKVM is very nice. I could have configured the system out of the box without ever attaching a monitor to.
The Supermicro/AST default Username and Password for IPMI is UPPER CASE and CASE SENSITIVE. I mistakenly thought I couldn't access the BMC until I configured it through the BIOS. The whole problem was the the default username and password were both all upper case.
As a result, the system is INSECURE out of the box. Change your IPMI/BMC username and password from the default as soon as possible.
IPMIView from Supermicro/AST is pretty nice. It is a standalone Java Application. However the web browser interface is just as good or better for a single system.
The BIOS watchdog feature causes the system to be reset every 5 minutes. Nothing is logged to the event log. Don't set it, at least until you understand how to use it. I think the Linux kernel is setting the hardware watchdog.
An improperly seated SO-DIMM, caused the system to hang at BIOS POST, with the code B4. However there were no beeps and I couldn't find a description of text error codes. The manual only gives the beep codes.

Hopefully this info will help others.

Amateur Radio information on modern social networking.

2014-12-28T13:05:00.000-05:00

I'm slowly starting to get some of the appeal of Reddit. At first I was drawn there by /r/rtlsdr, as there didn't seem to be much info elsewhere. There is a bit of a digital divide, for on-line sources many hams go to QRZ.com with it's 1990's design and god awful ads flashing all over the page. Try as you might, some of the old guys can't remember to try anything but QRZ.com. The other big source of info is Yahoo groups which are starting to show their age, but have been made much less useful due to Yahoo trying to figure out how to get more page views.

So two useful places to get answers to amateur radio related info:

Reddit: /r/amateurradio [http://www.reddit.com/r/amateurradio/]
StackExchange: ham.stackexchange.com [http://ham.stackexchange.com/]