From e10fb3b11a6f57bfcf845c1bf07ea069052b6e52 Mon Sep 17 00:00:00 2001
From: Camil Staps
Date: Tue, 17 Jan 2017 00:15:56 +0100
Subject: Ham pages
---
resources/jade/finals/ham/cw-decoder.jade | 77 +++++++++++++++++++++++++++++++
resources/jade/finals/ham/index.jade | 12 +++++
2 files changed, 89 insertions(+)
create mode 100644 resources/jade/finals/ham/cw-decoder.jade
create mode 100644 resources/jade/finals/ham/index.jade
(limited to 'resources/jade/finals/ham')
diff --git a/resources/jade/finals/ham/cw-decoder.jade b/resources/jade/finals/ham/cw-decoder.jade
new file mode 100644
index 0000000..bc8636b
--- /dev/null
+++ b/resources/jade/finals/ham/cw-decoder.jade
@@ -0,0 +1,77 @@
+extends layout-ham.jade
+
+block prepend menu
+ - var page = 'cw-decoder'
+ - var sections = ['Porting to PIC', 'Finishing', 'Future plans']
+
+block subtitle
+ | CW Decoder
+block subtitleDate
+ | January 2017
+
+block subtitle-right
+ +githubLink('camilstaps/CWDecoder')
+
+block page
+ h4 Introduction
+ p.
+ We discuss a small PIC-based CW decoder, a great help for a beginning ham.
+ The base is taken from Budd Churchward WB7FHC's #[a(href='http://www.mypetarduino.com/ReadCode/readCode.01.html') Arduino-based decoder].
+ My own source code, for a PIC16F88, is #[a(href='https://github.com/camilstaps/CWDecoder') on GitHub].
+
+ h4 Porting to PIC
+ p.
+ While the project is great, I was unable to resign myself to use an Arduino.
+ Arduino is nice for prototyping, but too many people use it as an end product, wasting space and resources.
+ Worst of all, they fail to learn principles of electrical engineering and programming on minimal architectures.
+ p.
+ Hence, I decided to port the project to a PIC microcontroller.
+ PIC is a wide range of microcontrollers developed by #[a(href='http://microchip.com') Microchip].
+ For this project, a simple 8-bit chip is more than enough.
+ The only thing we need to look out for is that the clock is fast enough.
+ I went with the #[a(href='http://www.microchip.com/wwwproducts/en/pic16f88') PIC16F88] which has 5MIPS, for the simple reason that I had it in stock.
+ Anything will do.
+ p.
+ Porting the Arduino code (which is a C++ dialect) to C is relatively easy.
+ The only complication is the millis() function.
+ On Arduino, this returns the number of milliseconds since startup.
+ This is part of the Arduino bootstrapping code, which we do not have on PIC, so a small wrapper for this function had to be written.
+ The same functionality can be achieved with a timer and an interrupt service routine (which is, I assume, the way it works on Arduino as well).
+ p.
+ For the LCD I used a 4x40 display with green backlight.
+ It is #[a(href='http://www.ekenrooi.net/lcd/lcd.shtml') HD44780]-based but has two control chips, which can be turned on and off using two enable lines.
+ My #[a(href='https://github.com/camilstaps/HD44780_PIC') HD44780_PIC] C library can deal with this, as well as with 4- and 8-bit interface.
+ (This is all done through preprocessing #define statements so it does not slow down the code.)
+ p.
+ Other than these two points, porting the code was straightforward and no major changes have been made.
+
+ h4 Finishing
+ p.
+ There was not much space left next to the display.
+ I had just enough space for the LED, the reset button and the volume button.
+ The LED is absolutely necessary on the front for feedback.
+ p.
+ The 4x40 LCD performs very well.
+ A 4x20 or perhaps 2x40 would do the job as well, but I wouldn't go smaller than that.
+ Sometimes characters are missed or noise is interpreted as a character, so you should expect that perhaps 80% of the character space is used for the actual text.
+ p.
+ There is no need to place the frequency potentiometer on the front because it should be fixed to your side tone.
+ I found that a high-precision potentiometer is very useful to adjust the frequency.
+ The bandwidth of the audio mixer is relatively narrow.
+
+ h4 Future plans
+ p.
+ I intend to make the decoded text not only available on the LCD but also on the UART module.
+ The RX pin is used already, but one-way communication will be enough.
+ This way, another module could log QSOs to an SD card, another idea I have been playing with.
+ p.
+ Another addition I'd like to make is a fix-frequency button.
+ This would disable the automatic adaption to the current speed.
+ It could be pressed at the start of a QSO and released afterwards.
+ I hope that in this way the decoder can become less sensitive to background noise.
+ p.
+ Lastly, some status information would be nice on the LCD.
+ Concretely, I'm thinking about the estimated WPM.
+ This should be fairly simple to implement.
+ It could also be useful to have an accuracy estimation.
+ Figures that could be used for this are the standard deviation on the length of dits and dahs and the amount of jitter during a dit or dah.
diff --git a/resources/jade/finals/ham/index.jade b/resources/jade/finals/ham/index.jade
new file mode 100644
index 0000000..5b1121d
--- /dev/null
+++ b/resources/jade/finals/ham/index.jade
@@ -0,0 +1,12 @@
+extends layout-ham.jade
+
+block prepend menu
+ - var page = 'home'
+
+block subtitle
+ | Home
+
+block page
+ p.
+ This is a collection of some Ham radio related projects of mine.
+ Perhaps it will be larger than this one day.
--
cgit v1.2.3