LoRa Radio for the Amateur Radio Operator

 LoRa is a long range spread spectrum modulation technique derived from chirp spread spectrum (CSS) technology. Generally these devices are long range, low power, devices that are used for the Internet of Things (IoT) networks. 

Generally these devices are low in cost, and programmable using the Arduino IDE. There are many different Arduino compatible boards now. LoRa is different than LoRaWAN - this project just uses LoRa devices, and the devices are all under $30.00 U.S. dollars. (most a lot less than that).  

There are several projects like this, actually a lot more then several. There are even a few specifically for Ham radio. Probably one of the better known projects is from Travis Goodspeed and is simply called LoRaHam https://github.com/travisgoodspeed/loraham. This project hasn't been updated in about 2 years. The LoRaHam project is one of the first, if not the first project specifically for amateurs. The project code is easy to read, and it is fairly easy to understand what is going on.  Travis is using Adafruit M0 LoRa Feathers, which are a little more expensive. The drawback was I did not see how it would scale, the other thing that I thought about was these are IoT devices, meaning you could set up a sensor network, but there was no provision for adding devices that were not "chat" devices.  A more recent ham radio project called LoRaMaDor by Elvis Pfutzenreuter https://github.com/elvis-epx/LoRaMaDoR. Was inspired by LoRaHam, this project is still active, and I've contributed some small python scripts to the project. This project was designed more as a terminal program. It uses ESP32 devices mainly because the sketch uses a lot of memory, and the ESP32s have plenty of memory.  This project uses a better, more scale-able protocol, which I believe is similar to AX.25, thou I'm not 100% sure about that. The main draw back to the LoRaMaDor is how big the sketch when it's compiled. It appears that it was designed to work with just the ESP32 hardware. I did not try it with a LoRa M0 because I don't own one. The other problem is the sketch is just confusing to someone who may not be a programmer. I have been programming for a while, but I only consider myself to be an intermediate programmer, and while I understood some of it, other parts just were confusing. Maybe in another 5 years I'll understand.

I am also aware of the Hamshield for the Arduino, and aware there is a "chat" sketch for that device, that can be found here: https://github.com/EnhancedRadioDevices/LoRaChat. I don't know anything about this device except that it at a slightly higher power output than the "cheap" IoT devices. 

My project which tentatively I am calling LoRaAPS or LoRa Amateur Packet Service. The name may change based on feedback, or it may not. I was inspired by both of the above projects, and APRS.

What makes this project different, I attempted to create something that is as simple to understand as LoRaHam, but with "real" protocols that can be expanded on, and scaled. I am treating the device as an IoT device, like it was designed to be. The protocol uses json, the gateway uses a MQTT broker. The device will beacon every 10 minutes (like LoRaMaDor devices), It uses some of the same settings as LoRaMaDor, but isn't directly compatible with that system. By using some common IoT systems, interfacing to the devices should be fairly easy and straight forward. 

The sketches were written to able to add or change LoRa hardware as needed. Currently the hardware I have is Two LoRa32u4 devices, based on the Arduino Leonardo, Two TTGO T-Beam v1 with Oled display and GPS, and 4 TTGO ESP32-Oled. 

LoRaAPS uses Repeaters (digipeaters), pagers, and gateway devices, the roll of the device depends on which sketch is loaded onto the device. However LoRa32u4 devices seem to lean to being digipeaters. 

Roles:

DIGIPEATER - These devices will repeat any packet that they get, there is limited checking, if a message is addressed to the DIGIPEATER it will not be repeated. IE: Our digitpeater's callsign is KD8BXP-10.  If we send a message to KD8BXP-10 and if the digipeater hears the message, the message will stop there. If these are hooked to a computer, you can use a terminal program to send messages, but currently there is no way to see a message addressed to the digipeater. Sketch is called "relay"

GATEWAYS - These devices will also repeat any packet they hear. Packets not addressed to them will also be sent to a MQTT broker. Packets that are addressed to them will stop, and not travel. ESP32 devices appear to be perfect for this role, because they can connect to a WiFi network. Like the digipeater there is a limited serial interface, for sending messages, they will not show messages addressed to them. GATEWAYS add a few more limited checks for messages, mostly so a message they have already send doesn't get resent either OTA or back to MQTT.

PAGER - these are mobile devices, because the "network" is relatively small/new, they will also digipeat any packet they hear. Devices with some type of screen work well for this role, ESP32 devices with OLEDs. These devices will show messages addressed to them on the screen. If using an ESP32 a bluetooth terminal can be used to send messages, or if you connect them to a computer a serial console can be used.  These devices will also show "BEACON", "CQ", "WX", and "BLT" special calls. 

SERIAL PORT:  Settings: All roles can send messages via the serial port if connected to a computer, PAGERs using ESP32 devices can also send messages with a bluetooth terminal.  Serial Port Settings: 8-N-1 9600baud, the newline code is used to indicate you are ready to send.  You may also want to turn on "ECHO" for your terminal program, just to make it easier to see what you are typing. For Bluetooth you must make sure the BT terminal program you are using can send a "newline" code.  *Using PUTTY or the Arduino Serial Console is probably recommended* 

CALLSIGNS: All devices need to have a callsign with two digit ssid,00 to 99, which gives 100 possible devices. Callsigns must be unique, otherwise problems will arise, missed messages, or messages not sent, and could create other issues. 

SPECIAL CALLS: "BEACON", "CQ", "WX", "BLT".  "BEACON" this is sent every 10 minutes as long as the device is on, the message it sends can be changed within limits (Remember to keep the message short if you want to change it) by Default it will send "DE: KD8BXP-00 LoRaAPS v1 pager" or something similar to that. "CQ" can be used to see if anyone is around that wants to chat, like a normal "CQ", to use just send "CQ some message".  "WX" weather information, this is for future expansion, but could be used to ask a sensor for information, or used to make general weather reports. (*Still a work in progress, however it can be used now). "BLT" is like a bulletin on the APRS system, this could be used to make a general short anouncement, Like "BLT KD8BXP-20 Gateway going off line" or "BLT Net tonight at 7pm on W8BLV 146.610 repeater". I considered adding "GPS", "NET" and "CHAT" - but thought between "BLT" and "CQ" that could cover "NET" and "CHAT", and I couldn't figure out what I really thought "GPS" would be used for.

ROUTING: Routing is based off APRS "hops". APRS recommends 3 hops, the path for APRS is recommended to be WIDE1-1, WIDE2-2. What this means is the first station that hears a packet will mark off the first WIDE1-1, causing the path to become WIDE1-1*, WIDE2-2. The next station will mark off one of the hops from WIDE2-2, causing the path to look like this WIDE1-1*, WIDE2-1, finally the third station that hears the packet will retransmit and mark off the last hop. The next station to hear the packet will not retransmit.  This project uses a count down, when the counter reaches 0, the packet will no longer be transmitted. Because all the devices also act as digipeaters the use of a specific call was not needed (IE: WIDE1-1). On each hop the station that repeats the packet will also add it's call to the packet. (* Not implimented yet * Ability to display the path the packet took)

PACKET: When sending a message to someone you may see something like this:  

{"T":"KD8BXP-00","F":"KD8BXP-02","M":"This is the message","R":3,"P":["KD8BXP-02","NOCALL1","NOCALL2","NOCALL3"]}

The above is a json string that is sent OTA, and if coming from a GATEWAY to an MQTT broker. Json  stands for JavaScript Object Notation, it's lightweight format for storing and transporting data. It is common to find websites that use JSON, it has also become a defacto standard for the IoT. For machines this is easy to read and understand, while for humans it may look like it doesn't make much since, it is actually pretty easy to read simple json. Originally the JSON for this project was going to look a little different, I had to make some changes because of limits of how much data could be sent over LoRa. IF we look at what I had originally thought, it might be a little easier for a human to read.

{"TO":"KD8BXP-00","FROM":"KD8BXP-02","MESSAGE":"This is the message","RT":3,"PATH":["KD8BXP-02","NOCALL1","NOCALL2","NOCALL3"]}

So, hopefully this makes a little more since. JSON is generally in pairs, so in the above example. "TO" and "KD8BXP-00" are together. This message is meant for the device that has the callsign "KD8BXP-00". "FROM" and "KD8BXP-02" are a pair, so KD8BXP-02 sent the message, "MESSAGE" well this should be self explanatory, it's the message that has been sent. "RT" and 3, this is the re-transmit counter, and will be updated with each hop. Finally "PATH" as you can see PATH is associated with a group as signified from the [ ] braces. But the idea is the same, as the simple example. "PATH" each time the packet is re-transmitted, the callsign of the transmitting station will be added, first spot will be the original call (yes, "FROM" and the first call in the PATH are duplicated.) NOCALL1 will be replaced by the first hop, NOCALL2 by the 2nd hop, and NOCALL3 by the 3rd and final hop.

To save some space when sending OTA, everything was shorten to the first character of what it represents. It does make it a little harder for humans to read, but when you know what they mean, it is still readable. "T" = "TO", "F" = "FROM", "M" = "MESSAGE", "R" = "RT", "P" = "PATH". For the TTGO T-Beam, another field was added for "C" = "COORDINATES" or latitude, and longitude. It will look something like the "PATH" field.  {"C":[38.39899,-84.4994]}. The TTGO T-Beam will add it's latitude and longitude to each packet sent. But currently no other device uses this information.

SENDING A MESSAGE: While all the various roles can be used to send a message, only a pager can currently display a message received. Because of this, I recommend only using the pagers to send messages. The easy way is to connect the pager to a computer and use a terminal program, see above for settings. Sending a message is "callsign-ssid message", a message of upto 77 characters can be sent. IE:

"KD8BXP-00 This is my test message"

With out the quotes, If you forget the ssid, or if the message is too long you will get an error message in the serial console. (*BT currently has no feedback, an updated version will be coming soon). CALLSIGNS can be entered in low case, or upper case as desired. This makes it simple to create programs that can interface with the devices. IE: python script, or other types of programs.

ARDUINO SKETCHES: I am not going to go into how to install the correct "board core" for your device, there hundreds of tutorials on that subject. I'm also not going to go into how to install a library, again, there are a lot of tutorials for this as well. I do want to say which libraries are required and were to find those libraries. 

1. LoRa https://github.com/sandeepmistry/arduino-LoRa
2. ArduinoJson (please use version 5.13.5) https://github.com/bblanchon/ArduinoJson
3. TimedAction https://playground.arduino.cc/Code/TimedAction/
4. SSD1306Ascii https://github.com/greiman/SSD1306Ascii
5. PubSubClient https://github.com/knolleary/pubsubclient
6. (for the T-Beam Device) TinyGPS++ https://github.com/mikalhart/TinyGPSPlus
7. (for the T-Beam Device) axp20x https://github.com/lewisxhe/AXP202X_Library

Sketch names: gatewayLoRa32, pagerLoRa32, pagerT-Beam, relay32u4, relayLoRa32

GatewayLoRa32 - This is written for the ESP32 devices (LoRa32-Oled) the display is not used, this will gate messages to a MQTT Broker. see GATEWAYS above. 

 PagerLoRa32, PagerT-Beam - these are written for the ESP32 based boards, with OLED display support. The T-Beam version also adds GPS support. See PAGERS above.

Relay32u4, RelayLoRa32 - These are digipeaters, Relay32u4 was written for the LoRa32u4 boards, while RelayLoRa32 is written for the ESP32 device, no OLED display, these will just relay (digipeat) see DIGIPEATER above.

The sketches are written in such away that if you do not have a ESP32 or LoRa32u4 or T-Beam, you should be able to adapt the sketches to work with what you do have. * Please share if you have other hardware, let's extend the project and make the network better. *

LORA SETTINGS: LoRa settings should be considered for each area, the only thing to consider is frequency to use. The current project uses 433mhz hardware, with a spreading factor of 9, coding rate of 5, tx power of 17, and bandwidth of 62500. Every device using the network has to match, frequency, and the above. These can be local settings however, and don't have to be used globally. But if you want to communicate with another ham in your own town, the settings do have to match each other. 

MQTT BROKER: MQTT is a lightweight messaging protocol for small sensors and mobile devices, optimized for high-latency or unreliable networks. Originally designed by IBM in 1999, it was used to monitor oil pipelines. The goal was to have a protocol that is bandwidth-efficient, and uses little battery power. This is a publish/subscribe with topic hierarchy. IE: Device 1 publishes a message "Light ON" to topic "LIGHTS", Device 2 (The light) subscribes to the topic "LIGHTS" and acts on the message "Light ON". For this project, the gateway subscribes to the same topic it publishes too, this is a little strange, but not unheard of, our gateway will filter out it's own messages, it will also filter out invalid JSON.  The project currently uses a public MQTT broker, because of this anyone can subscribe or publish to the topic (an attempt was made to make the topic hard to remember, but not impossible). Also because this connection could be seen by the public consider every message sent to be in the clear, don't send sentive information. 

Because MQTT is a common and standardized protocol, phone apps, python scripts, or custom written software can be used to expand on the network, and make the network more useful.

* IF this project gains lots of users, it may make more since to more to a private broker, at which time the project would need to gain funds to fund that broker. 

** A Raspberry PI could also be used as a broker, this might be good for keeping information within a local network, and not gated out to the world. If you choose to go this route, you might also consider using a MQTT bridge to bridge to more/other networks. http://www.steves-internet-guide.com/mosquitto-bridge-configuration/

RECOMMENDED SETUP: At this time the "network" is small, very small. So I would recommended setting up at least one gateway, one relay (digipeater), and one pager. Good antennas are almost a must for this project, but they will work with the stock "antenna".  DIGIPEATERS should be on higher ground,  while a gateway can sit on your desk to make it easier to connect it to the internet. PAGERs can either be mobile or stationary. SSIDs - there is no hard or fast rule to this, I would recommend using higher numbers for your GATEWAY and DIGIPEATERS, leaving the lower number ssids for the PAGERS.  IE: GATEWAY - KD8BXP-70, DIGIPEATER - KD8BXP-80, PAGER KD8BXP-00, or PAGER KD8BXP-01. If you plan on deploying some sensors you may want those to be in the 50 or 60 range. This are just recommendations, and are subject to change based on feedback, and other factors.

Sept 12, 2020 - v.5, documentation written. github repository created, code not yet published. 

Echolink on Linux - Ubuntu 10.10 notes

These are just a few notes I have on installing and using Qtel on Ubuntu 10.10 64-bit Linux.

I came across the following blog post a while back, and for the most part, this is what I did to get Qtel to work on 10.10, there are a few things that are different.

http://charlessocci.com/2010/07/06/echolink-qtel-client-ubuntu-10-04-64-bit/

I found the 2nd download link to have better information about the order to install each file.
These have already been made into a Debian package, however if you want to install from the source (beyond, the scope of this blog) the source can be found here: http://sourceforge.net/projects/cqinet/files/
The link to the Debian package is here:
http://lz5pn.homeip.net/lz5pn/echolinux/qtel-debian.tar.gz This tarball also has the getlibs package in it.

Install in this order:

1 getlibs-all.deb
2 echolib_0.13.0-2_i386.deb
3 libasync_0.16.0-2_i386.deb
4 libsigc++1.2-5_1.2.7-2_i386.deb
5 qtel_0.11.0-2_i386.deb

After this run this command as root:

getlibs /usr/bin/qtel

if you are using a 64-bit OS you'll probably need to go ahead and force them to install

sudo dpkg -i --force-all ......

The website that I found that link on said all you need is the qtel_0.11.0-2_i386.deb file to install, this isn't true, I found that all of the lib files also needed to be installed. So follow the order in the tarball.

Next thing, it says to change the directory server option in Qtel (both say this) I found that I didn't need to change the server, so I'm not sure why they say to do this.

It is at this point thou, that you will probably want to run the application.
and where I found the biggest problem. Simple but "weird" fix to it.
The default location for the install in the menu is under Applications->Internet->Qtel

The program will start, run and connect, but has no audio (either input or output).
The simple fix to this for Ubuntu 10.10 is running the application with the following command:

padsp -M /usr/bin/qtel

(I went ahead and modified using the menu editor the Qtel entry, on my system)

Here is the "weird" part thou. This method only works, if I you also open up the "Sound Preferences" from the System -> Preferences -> Sound menu.
IF the Sound Preferences is not open, you'll still not get any audio. But with it open you get audio on both the input & output.

I'm not sure why this is, my only guess would be a bug in padsp. But I spent a couple of hours trying to get the application to work, and finally found a similar problem someone else was having, and that was the key. So hopefully you have come across this blog before spending hours trying to figure it out.

And if you know of a fix for the "weird" fix, let me know, I'd rather not have to open up sound preferences if I don't have too.

Using PHP-cli to send APRS-IS messages

I really can't take credit for this script, I can only take credit for modifying it to send messages into the APRS stream.

The original script can be found here:
http://boxoblog.wordpress.com/2011/02/18/php-telnet-script-to-connect-to-tor-and-refresh-ip-address/

IT is a quick/dirty modify, and still needs to be tweeted, but here is the basics of it:

function tor_telnet($ip,$port,$auth,$command) {

//$fp = fsockopen($ip,$port,$error_number,$err_string,10);
$fp = fsockopen($ip,$port);
//if(!$fp) {echo “$error_number $err_string“;
//return;} else {
fwrite($fp, $auth . "\n");

$received = fread($fp,512);
echo $received;
sleep(10);

fwrite($fp,$command."\n");

echo "\n";
$received = fread($fp,512);
// list($rcode,$explanation) = explode(‘ ‘,$received,2);
echo $received;

//}
fclose($fp);
return;
}

//tor_telnet(’127.0.0.1′,’9051′,’password’,'signal NEWNYM’);

tor_telnet('aprsdcsp.ka7o.net', '1314', 'user KD8BXP pass PASSCODE', 'KD8BXP>TCPIP*::N4TRQ-9 :telnet script ack via twit');




I keep getting an error in the original script on line 5, I just didn't spend time to figure it out, and ended up commenting out the whole line. I also changed the fsockopen line thinking that may have been causing the other problem.

So, it's quick and dirty, logs into the message stream on APRS-IS, authorizes your callsign to send messages, waits a few seconds, and sends the message.

This is the line that makes the magic happen:
tor_telnet('aprsdcsp.ka7o.net', '1314', 'user CALLSIGN pass PASSCODE', 'KD8BXP>TCPIP*::N4TRQ-9 :telnet script ack via twit');

1st is the server to use, you'll probably want to change this, 2nd is the port number, in this case it's the message port, 3rd is the authorization request, just replace CALLSIGN with your base call, and PASSCODE with your APRS-IS passcode. (This is the same code that other APRS apps use, so you may already know it, if there are a few apps that will tell you it)
The last thing is the aprs message it's self: This took me a while to figure out, but I finally found some documentation on the right format to use.

SO, let's look at the message string:
KD8BXP>TCPIP*::N4TRQ-9 :message
^^^^^^
|- Your Callsign (can use SSID)

KD8BXP>TCPIP*::N4TRQ-9 :message
^^^^^^^^^
|- This needs to be left alone, do not change it

KD8BXP>TCPIP*::N4TRQ-9 :message
^^^^^^^^^^
|- The destination call (NOTE: IT"S 9 DIGITS and then a colon, N4TRQ-9 is 7 digits, so you need to add 2 spaces, if you were just using the base call N4TRQ you'd need to add 4 spaces THIS IS IMPORTANT)

KD8BXP>TCPIP*::N4TRQ-9 :message
^^^^^^^^
|- the message to send, remember no more then 60 characters

The Colon separate everything and need to be there.

So, probably a better way to do the string would be:
$call = 'KD8BXP';
$dest = 'N4TRQ-9 ';
$msg = 'This is a msg';


tor_telnet('server', 'port', 'authorization', $call . '>TCPIP*::' . $dest . ':' . $msg);

Yes I put the spaces in the $dest variable - but you could write a quick check, and add the spaces just as well.

Anyways, hope this helps you out, I use PHP and the CLI (Command Line Interface), but I don't see any reason why this simple script wouldn't work on a web server.

response to POCSAG Paging – Ideas By KC8GRQ

Below is my response to Marks POCSAG Paging - Ideas (KC8GRQ)
That can be found here:
Paging Ideas
I couldn't get his "CAPTCHA" system - I am a real person I promise!


Mark
I do like the idea of the hy-bird system, connected and unconnected systems -> but I think that will just lead to problems, the more I think about it...the more I wonder how you would get the page information to the non-connected systems without some sort of RX/TX combination....which leads to the PL tone, which leads to the (well...you know)...

A hy-bird system may sound like a good idea...but I am not so sure it will work the way we want it to.

I admit, my idea needs some work, it's was a rough idea this morning....but it still makes since to me...it really does.


I think we also need a fall down patern -> IE:

APRS (lat/lon), (Foursquare, Geoloqi, other Lat/Lon services), Dstar (last repeater connected to via RF), Allstarlink/echolink (???) I don't think we can really use IRLP (It is VoIP, but it doesn't contain a call sign - so no way to really know who is connected unless we are listening to it)

Your right, the TX site wouldn't need to add anything to the pager - since the server system would know where it's going to send the message it can just add that information right at the start. And that makes since... having the TX stations CW id makes since too. (The software would need to be smart enough to not transmit while it's CWing like you hear on some repeaters)

I was thinking about the cap codes as well...this would be a nationwide system, but if we did something like just "push" the page to the right TX site, cap codes become less of an issue, since only 1 TX would get it...you'd just need to make sure that people in your area are not using the same cap-code

IF you do travel a lot or a little, you'll just be aware you could get a message meant for someone else...for the most part none of this is truly private - think about messages on APRS, anyone who knows where to look can get those messages. So they are not private at all.

But you do want to try and avoid using a cap code over and over and over again as well...So a published list of codes should probably be on the website someplace.

The idea being that if you know a ham has a pager - all you need is his/her call sign to get them a message of course.

I would have to check again, but I think to stay legal we need to also be able to store the messages that are sent, and where they were/who sent to.

But that should be easy to do in a mysql database.

I don't know lots to think about still...and honestly I don't know which system will be better, the RX/TX combination or the closest TX site

As I said both have the good and both have the bad. I know it would take some work to get a database of the locations, but I am pretty sure we want to do that anyway.
Getting the APRS data is easy (lat/lon) and the calculations to figure out how far something is from something else is easy I've got the code to do that.

So yes, some work needed, but nothing that would be overly hard to do.

Personally (and it's a personal thing) I know how lazy I am - the last thing I want to do if I'm going to go somewhere is log on to a site and tell the site where I will be and when...I would rather just have the site "follow" me automatic
I do see a problem with that, now we aren't putting a load on the RF side of things but could be putting a load on the computer site of things....
SO, maybe if we made something like...send a email to the system to tell it to follow you...or log-on the system and put it in "Travel" mode...then it would only follow you if you told it to.

I don't know - lots to still work out...I just don't think you want people to say where they are or will be...things happen (and if you don't have access to the net you'll not be able to update the site yourself) if the site follows it will know where/when you are someplace. (Within reason)

Just some more of my thoughts on the subject. I don't know which would be the best...My thought money wise it would be cheaper for the end user to setup a TX point then a RX/TX point - less hardware needed (assumes you already have a computer you can use - but if you don't have a computer why would you build an encoder LOL)

Ok, just my 2cents.

Random Thought of the Day!

I had one of my random thoughts today - wondering if a allstar link server will do it -> Thinking about setting up a phone number that I can call my DSTAR radio here at the house and use it here while I am mobile over the phone...I know it is a random off the wall idea -> Allstar Link does have a phone interface thou so just wondering if it could be done.

Playing around with Colorizing Black & White Photos

Today, I decided that I needed/wanted to try my hand at colorizing some of my Grand Fathers (W8FVW) pictures. There were all in black and white, and I thought hey, how hard could this be! We have very powerful computers, right?

Well, I found just the opposite to be true, The software is either very bad, or very expensive, I downloaded trial version of many different programs. I tried Gimp, I tried many online websites, nothing I tried was automatic, Maybe I was asking too much, maybe I thought it should be easier to do, I don't know. The only program that I found that made it easy to do, (And easy is the key!) You still had to tell it what to do, but once you told it....it did it.

Was a program called recolored, it let you try before you buy, 21 days, not bad unless you have a lot of pictures, but it is also affordable. At the time of this writing I believe it is $30 bucks.

It does take some reading to start using it, you can't just use it out of the box, there is no "Wizard", but it is easy to use, it give general pallets of colors for skin, sky, stone, metals, cloths, ect...you also have full access to the full pallet if you just can't find the color you need or want.

Get the color, and outline the area you want that color to fill in. after you get all your areas done, hit the colorize button, and watch it work.

I did four pictures in about 20 mins I guess. The first one, Was me just playing and testing, I want to go back and make it better now that I know a little more about what I am doing.
The 2nd, I keep tweaking it till I was happy, Which didn't take long, I was pretty happy with the 3rd picture.

The 3rd picture, I just did one time, simple picture, was very happy with the results 1st time around, took about 5 mins to do.

The 4th, Was not of a person or car, but of vintage ham radio gear. IT was a bit of a challenge because the room was all white, the radios mostly dark color, and sitting right on top of each other.

But it didn't take long, and I was pretty happy with the end results, it probably could use some tweaking, but for what it is...

So here are the before and afters:

Picture number 1:






Picture number 2 (and the 3 after photos):











Picture Number 3:






Picture number 4: (Some of his radios):






Also, while I was messing around with the Black and White Photos, I thought it might be interesting to try and convert the 2D images to 3D -> These pictures were not taken in 3D, but learning a few things about how the anaglyph (red/cyan) work, I thought, again, we have computers now, it shouldn't be that hard to do.

And it wasn't. Using GIMP, I make a layer from the image that is visible - now there are two images showing in the layer menu. make the top layer visible, move the offset (I used a negative offset, and I had to set it pretty far, at least -150 to -285), then using the plug-in I blogged about early this month, I turned it into a 3D anaglyph. and for the most part, it did work.

I think because the offset is so far off on them pictures, I started to see a "Ghost" if I was far away from the monitor, up close it did seem to be good.

So the 1st picture, is my Grand Father, and Grand Mother, the original is already posted above.



The 2nd is I think my Grand Father (Man in the back Center), at a boy scout Ham radio station






Conclusion - While 3D anaglyph have gotten very easy to do, a truely "Easy" way to convert a black and white photo to color is probably still a dream away, but it is getting easier to do!

Thanks for reading my posts,
LeRoy, KD8BXP

Woke up this morning with an idea

I woke up this morning, with this idea, and I can't seem to get it out of my head, but the more I think about, the I think of trouble that may come from it.

- Not too long ago, I did a DV dongle, using skype, and a VNC - I didn't transmit on this, thou I am sure I could have, I just used it to listen to my DV dongle.




Taking this idea to the next "logical" step would be to cut out skype, and use two radios, and a Signalink usb soundcard adaptor. I already have everything I need to do it, I have a FT-817 hooked to a signalink, and I have the WIFI connection for the VNC, plus I have my HT, and my mobile rig.

The more I thought about this thou I wondered how to ID the stations? I would be the control for both stations, and if I really wanted to I could use this from any place my home station could recieve my hand held, and as long as there was a internet connection, there would be no reason I couldn't VNC to my home computer and use it to get on DSTAR.



I have seen kind of the reverse of this idea, where you can turn a radio that has a 9600 baud packet port into a DSTAR radio -



my idea was analog to anlog, SO it shouldn't matter if there is a 9600baud packet port or not, since the DV dongle would be used to key into the dstar system...or is my thinking just wrong on this?

A truely adventurous type could, make their DV dongle available to other hams, an allow them access to the VNC...then that opens up a whole new can of worms.... I know.


I may never do this, (I have 2 DSTAR radios, so it's just an idea) or I might do it once just to see on really low power, I would be curious thou if anyone else has done this or even thought about doing it :-)

LeRoy, KD8BXP