pizone – Raspberry Pi based Nintendo Zone access point

I have just released a project called pizone that uses a Raspberry PI, along with some NodeJS code to create a customer Nintendo Zone access point. This allows you to connect your Nintendo 3DS to the point, and get Spot and Street Passes (along with other game specific items) from players around the world.
You can see a quick video here:

Features include:

Creates a portable and custom Nintendo Zone access point.
Automatically loops through known Nintendo Zone access points to allow you to make Street Pass contacts from around the world.
Can add additional access points.
Web based interface to monitor status, and tweak some settings.

Basically, it uses a Raspberry PI with a USB wifi dongle to create a wifi access point. The pizone software (mostly written in JavaScript / node) then loops through a list of Nintendo Zone access point addresses every 10 minutes, giving you Street Pass contacts for anyone else using or visiting that access point (as well as Spot Pass content).
I actually did most of the work about two years ago over Christmas break, but never got around to posting or releasing the code until today. It is released under a BSD license, and you can grab everything over on the project’s github page.
Im not actively developing it, although if there is interest, then Ill try and make some better install docs. If you have any questions, need help running, or want to fork the code, then just post in the comments, or over on the project’s page on github.

Link: http://feedproxy.google.com/~r/MikeChambers/~3/GX2uPyq7BXw/

Example JT65 QSO Exchange

I recently received my amateur radio general license and setup my station. One of the first formats I was interested in was JT65, as it provides good reception, even with poor signals, and it has a fairly structured format which makes it a bit easier to start with. So, what is JT65? From Wikipedia:

JT65, developed and released in late 2003,[3] is intended for extremely weak but slowly varying signals, such as those found on troposcatter or Earth-Moon-Earth (EME, or “moonbounce") paths.[2] It can decode signals many decibels below the noise floor in a 2500 Hz band (note that SNR in a 2500 Hz band is approximately 28 dB lower than SNR in a 4 Hz band, which is closer to the channel bandwidth of an individual JT65 tone), and can often allow amateurs to successfully exchange contact information without signals being audible to the human ear. Like the other modes, multiple-frequency shift keying is employed; unlike the other modes, messages are transmitted as atomic units after being compressed and then encoded with a process known as forward error correction (or "FEC"). The FEC adds redundancy to the data, such that all of a message may be successfully recovered even if some bits are not received by the receiver. (The particular code used for JT65 is Reed-Solomon.) Because of this FEC process, messages are either decoded correctly or not decoded at all, with very high probability. After messages are encoded, they are transmitted using MFSK with 65 tones.
Operators have also begun using the JT65 mode for contacts on the HF bands, often using QRP (very low transmit power); while the mode was not originally intended for such use, its popularity has resulted in several new features being added to WSJT in order to facilitate HF operation.

After I made my first two contacts (QSOs), I shared with my friends on facebook. One of my friends was curious how the message exchange actually works, and I thought it would be useful to write it up as a general reference for understanding the JT65 message format, and contact exchange structure.
JT65 is a very structured format. Each message can contain 13 characters, and takes a little under a minute to transmit. This means that one person will send on even minutes, and one will send on odd minutes. It also means there is not much opportunity to send free form text (although you can send a small amount at the end).
Here is a screen shot of some JT65 activity, including two contacts (listed on the right).

Lets look at one of the exchanges, and walk through it step by step to get a better understanding of what is going on.
Lets step through one of the contacts where I put out a call to contact with someone else.
First, with the exception of the call for CQ, the format of each message is: : <FROM> : <MESSAGE>


This is the start of the message. Here I (W6MSH) am calling CQ, which is basically saying I am looking to make a contact with someone. The last part of the message, CM87, gives my 4 digit maidenhead grid location, which gives a general area of my location.

VA7EEX responds to my CQ call, and provides his maidenhead grid location (CN89).

I then send a signal report to VA7EEX. The report of -7, is given in decibels, and describes how well the message is being received. The higher the value the better, with 0 being the highest.

VA7EEX then responds, acknowledging my signal report (R), and providing a signal report for the reception of my transmission (-14).

I then respond and acknowledged his signal report (RRR)

VA7EEK then ends his transmission and contact (73).

I then respond ending my transmission and contact (73)

Couple of things to notice. First, based on the signal reports, you can see that I was receiving VA7EEX’s signal much better than he was receiving mine (about 4 times stronger). This is probably because I was transmitting on a frequency / band (40 meters) with an antenna that is not tuned for that band.
Also notice that there is not really much room for free-form text. The only real exception is in the last messages where you could include some text (keeping in mind it is limited to 13 chars, and you should include 73 to make it clear you are done with the contact).
Hopefully this is useful in understanding the format. I find it is a good digital format to start with, as the messages and contact exchange is very structured (and a lot of it is largely automated), which reduces the changes of getting something wrong.
You can find some more information on JT65 here.

Link: http://feedproxy.google.com/~r/MikeChambers/~3/K0oKbMqyQrU/