TF0 APRS Stafvarpi / TF0 APRS Digi

For a school project I designed an APRS standalone digipeater. It’s not perfect and could use some rework but the schematics and eagle cad files are available at https://ulfr.net/aprs/Stafvarpi.zip.
It uses Extdigi as software (which could use some rework). I’ll be posting updates on the design here.

Posted in Almennt | Leave a comment

uBITX Sendiviðtæki.

Nýverið pantaði ég mér uBITX sendiviðtæki eftir miklar spekúlósjónir um hvaða stöð ég ætti að fá mér til að fikta við HF hér heima við. (Aðallega fyrir WSPR og FT8). Á meðan ég lét mér leiðast í Andenes, í norður Noregi, starandi á gögn frá ACE og DSCOVR gervitunglunum, fékk ég þá flugu í hausinn að panta eitt stykki.

Það er að sjálfsögðu ekki komið enn, enda tekur lengri tíma en það að fá hluti senda hálfa leið yfir hnöttinn (amk þar til einhver finnur upp á ódýrari aðferð til að senda pakka með eldflaugum, Elon Musk, ég er að horfa á þig!)

En TF3JA, Jón Þóroddur heyrði af þessum áhuga mínum og hann lumaði á einu eintaki sem hann hafði ekki haft tíma til að fikta með, og lánaði mér eitt með því skilyrði að ég myndi nota þá þekkingu til að miðla áfram. Það er einmitt hlutverk þessar póstar. Þessi póstur verður líka uppfærður með tilvísinum hingað og þangað.

Fyrst smá kynning á tækinu. uBITX er framleitt af HFSignals og er lítið sendiviðtækis “kit”. Það er tiltölulega ódýrt eða um 130USD fyrir sett með sendingu og auðvelt í samsetningu, helsti ókosturinn við það er að það kemur ekki með neinni umgjörð og þarf maður því að sjálfsögðu að smiða hana sjálfur, helst úr málm þó margir hafi einfaldlega 3d prentað keisingar utan um stöðina. Leiðbeiningarnar sem ég hef fundið á neitnu eru dálítið kaótískar og maður fær á tilfinningunni að viðkomandi sé með ADHD, sérstaklega sá sem lét sér detta í hug að nota HMI Nextion display við stöðina. Þar sem ég hef nýverið fengið þetta í hendurnar ætla ég að láta þessi orð duga í bili, en á næstu vikum mun ég fara yfir hvernig á að púsla þessu saman svo úr verði sæmilegt HF sendiviðtæki sem má nota í hitt og þetta, hvort sem menn eru fyrir SSB phone, CW, eða stafrænar mótanir eins og FT8, WSPR o.f.l.

Posted in Almennt | Leave a comment

Uppsetning á APRS stafvarpa í TF. #1 Að byrja.

Langt síðan ég hef skrifað nokkuð hérna inn en nú ætla ég að taka mig á og skrifa seríu af greinum sem innihalda upplýsingar um hvernig á að setja upp APRS stafvarpa á Íslandi svo þeir fylgi þeim stöðlum sem APRS-TF ráðið hefur sett sér.

Fyrst ætla ég að fara yfir nokkur atriði sem þarf að hafa í huga þegar setja á upp APRS stafvarpa. Til að byrja með, hvað er stafvarpi? Stafvarpi (e. digipeater) er stafrænn endurvarpi (e. digital repeater) sem tekur inn stafrænt mótað merki, vistar það í minni, og sendir áfram, oft á sömu tíðni, en ekki alltaf. APRS kerfið á Íslandi gengur allt á simplex sendingu og móttöku og er því eingöngu á 144.800MHz. Móttaka er á nokkrum stöðum á 144.825 sem er gervihnattatíðni APRS. Það eru í grunnin tvær tegundir af stafvörpum reknar hér sem annars vegar er W1 sem er hugsaður sem uppfylling til að ná hærri stafvarpa sem nefnist W2. TF3SUT er dæmi um W1 stafvarpa en TF3APB er dæmi um W2 stafvarpa.

Gott er að hafa nokkur atriði í huga áður en farið er af stað að setja upp stafvarpa.

  • Er þörf á stafvarpa á því svæði sem ætlun er að koma upp stafvarpa?
  • Er annar W2 stafvarpi innan 50km radíus?
  • Á að setja upp W2 eða W1 stafvarpa?
  • Á stafvarpinn að vera nettengdur? Almennt er mælst með því að W1 stafvarpar séu einnig internet gáttir (IGáttir) en W2 stafvarpar þurfa þess ekki, en engu að síður er það kostur.
  • W1 stafvarpar hafa litlar kröfur um staðsetningu eða almennar uppsetningar hvað varðar búnað, sendir og loftnet. Annað gildir þó um W2 og er gott að hafa í huga það sem talið verður síðar.
  • Hvert er hámark kostnaðar sem má hljótast af framkvæmdinni?

Byrjum á W1 stafvörpum.

Hugmyndin með W1 stafvörpum er alla jafnan að fylla uppí svæði þar sem erfitt er að ná sambandi við W2 stafvarpa. Gott dæmi eru holtin og túnin sem ná illa inná W2 stafvarpa. Í flestum tilfellum eru svona stafvarpar hentugir heima hjá radíóamatörum (eða eins og í mínu tilfelli, heima hjá foreldrum mínum þar sem TF3SUT-2 er alla jafnan starfræktur). Með svona uppsetningu getur maður verið viss um að ná sambandi í kringum sitt nánasta svæði og á meðan maður er að slá garðinn eða týna uppskeruna úr jarðarberjakassanum útí garði. Uppsetningin sem ég mæli fyrir W1 er þokkalegt net sem skorið er fyrir 2m á amatöratíðnum og staðsett á þokkalegum stað á húsþakinu eða hvar sem því verður best komið, TNC-PI með Raspberry Pi er mjög hentug uppsetning en nota má hvaða TNC og tengja það við hvaða tölvu sem er með KISS staðlinum. Helsti kostur við W1 +Igátt uppsetningu er að þá er verið að byggja upp litlar einingar í APRS sem auka drægni en hafa ekki mikil víðdreifðaráhrif með áhættu á árekstrum í loftinu. (Nánar um það í næsta pistli) Uppsetningin mín er sem segir:

  • Loftnet: TRAM lofnet úr bílanaust ofan á skorsteini hússins. (~12þús kr)
  • APRS Merking I#, T& eða R& eftir því sem við á. (I# Stafvarpi með igátt, T& Igátt sem sendir og móttekur, R& IGátt sem einungis móttekur)
  • Talstöð er KT8900 sem kostar 60USD á ebay. (var rétt rúm 8þús hingað komin)
  • Módem er TNC-PI sem kostar um 40USD frá Coastal Chipworks.
  • Tölvan er Raspberry Pi sem fá má í íhlutum og miðbæjarradíó sem og á netinu fyrir einhverjar ~10þús kr með spennugjafa, minniskorti og hulstri.
  • 12V 6A spennugjafi fyrir talstöð (8~15þús kr í íhlutum eða miðbæjarradíó)
  • RG214 kapall (1200kr meterinn í Eico og nokkur tengi eru c.a. 2~3þús kr) (Ef vegalengd er undir 12metrar er engin sérstök ástæða til að nota RG214 og má vel nota RG213 eða RG58 hvort sem það er low loss eða venjulegur)

Eins og sjá má er þetta nú engin sérstök ósköp í kostnaði. Sé maður radíóamatör á annað borð er sumt af þessu jafnvel að finna heima fyrir eins og kapla, talstöðvar og fleira, sem og annað má jafnvel finna á netinu fyrir minna. Í þessum tölum er auðvitað ekki minnst á hluti eins og suðuteip, bolta og festingar og annað tilfallandi, en slíkt er nú oft hægt að fá lánað hjá APRS-TF ráðinu sem og aðstoð við uppsetningu búnaðar. En förum yfir kosti við W1:

  • Kostnaður ~50þús og má halda neðar sé búnaður til fyrir.
  • Fín uppsetning heima fyrir sem bíður uppá áframhaldandi fikt (setja upp veðurstöðvar og allskyns gagnamælingar)
  • Skemmtilegt föndur við að koma upp búnaði heima fyrir án mikilla framkvæmda.
  • Margt smátt gerir stórt, því fleiri sem koma upp APRS W1 stafvörpum með igáttum þeim mun traustara er APRS-TF kerfið.
  • Kynnast þeim skemmtilega hóp sem APRS-TF er.

En hvað með W2 stafvarpa?

Þarna erum við komnir út í töluvert stærri pakka með mun ríkari kröfum en fyrir W1. Ástæðan er mjög einföld. APRS í grunnin gerir ráð fyrir leiðarferlinum WIDE1-1 fyrir uppfyllingar en WIDE2-n á að ná til breiðari hóp einstaklinga. Sem dæmi má nefna að TF3RPF (Síðar TF3APA), TF3APB og TF5APA sinna mjög stórum svæðum. TF3APB nær frá Hvolsvelli og suður að Reykjanesbæ og loks norður fyrir Akranes, og sjálfsagt lengra ef hann væri prófaður með fleiri wött í farteskinu. Því þarf að huga mun betur að staðsetningum W2 stafvarpa en að W1 og hafi menn í hyggju að setja upp W2 stafvarpa er lang best að hafa beint samband við okkur í APRS-TF ráðinu sem finna má á facebook og einnig er hægt að senda mér beint póst.

Staðsetningar eru mjög krítískar fyrir W2 stafvarpa. Við viljum hafa þá eins hátt uppi og hægt er og má nefna að TF5APA er á Vaðlaheiði í Eyjafirði, TF3APB er í Bláfjöllum í 20m háu mastri og TF3RPF situr í mastri ofan á Hraunbæ í Árbæ. Á áætlun er að koma upp fleiri W2 stafvörpum og má nefna nokkur dæmi.

  • TF8APA á Þorbjarnarfelli við Grindavík (Áætlað vetur 2017)
  • TF1APA á Búrfelli í Árnessýslu (Áætlað seint 2017 eða snemma árs 2018)
  • TF2APA á Heiðarhorni við Borgarnes (Fjallatoppsenduvarpi áætlaður sumarið 2018)
  • TF9APA á Þrándarhlíðarfjalli (Áætlað sumar 2018)
  • TFxAPx á Fjórðungsöldu (Áætlun liggur fyrir en ekki vitað um tímasetningu)
  • TFxAPx á Strút norðvestan við Langjökul (Áætlun liggur fyrir en ekki vitað um tímasetningu)

Kröfur um módem eru hin sömu og fyrir W1 en ekki er gerð krafa um að W2 stafvarpar séu internettengdir þó slíkt sé ótvíræður kostur. (Ætlunin er að Igáttar væða TF5APA sumarið 2018). Á þessum lista má þó sjá að það er fullt af stöðum á landinu sem enn vantar APRS stafvarpa fyrir landsdekkandi kerfi, má sem dæmi nefna Austfirðina alla og Vestfirðina sem og megnið af miðhálendi Íslands. En lítum aðeins á uppsetningu á TF5APA.

  • Stafvarpi í sendahúsi á Vaðlaheiði í Eyjafirði.
  • Loftnet er 3dBi 2m fibernet og  situr á toppi sendahúss í þríforki ásamt neti F4x4.
  • Er í um 600m hæð yfir sjávarmáli
  • Sendir er VX-2000 VHF stöð 25W
  • Sía er Band pass cavity tunna stillt á 144.800MHz
  • Aflgjafi er frá Yaesu.
  • Módem er TNC-X með X-digi dótturborði.
  • Kapall er RG213.

Þarna má sjá að örlítið meira er lagt í uppsetninguna en á W1. En skoðum síðan TF3APB í samhengi við TF5APA. Þess má geta að TF3APB er úti þegar þessi grein er rituð eftir að óveður tók niður loftnet með meiru. Stefnt er á viðgerð á næstu dögum.

  • Stafvarpi er í sendahúsi Radio.is í Bláfjöllum.
  • Loftnet er Kathrein Dipole efst í 20m mastri. (Sambærilegt net á 300~500USD á ebay)
  • Er í um 700m h.y.s.
  • Sendir er FT-2800 50W. (100 ~150 USD á ebay)
  • Sía er Band pass cavity á 144.800MHz (300+USD á ebay)
  • Aflgjafi er frá Yaesu (50~100USD)
  • Módem er TNC-PI með Raspberry Pi (verður síðar nettengd við 4G og fjarstýranleg) (c.a. 15þús kr m. aflgjafa og korti)
  • Kapall er 1/2″ hard liner coax. (Verð rokkar frá 500~1200kr meterinn, tengin enn dýrari)
  • Eldingarvari er á áætlun á coax. (c.a. 20USD á ebay)

Þarna má sjá að kostnaðurinn er aðeins kominn upp sem og vesenið í kringum þetta. Eina leiðin uppí bláfjöll er gangandi, með jeppa (að sumri til), snjósleða eða skíðalyftu að vetri til. Smáefnið sem er tilfallandi líka rýkur upp í kostnaði þar sem allt þarf að vera algjörlega pottþétt, smá ísing getur valdið því að kapall er ónýtur ef rangt er staðið að verki. Sem og að á hverjum stað þarf að semja við þá sem halda útí viðkomandi sendastað. Það gefur því auga leið að W2 stafvarpar þurfa að lúta að ríkari kröfum, sem og að umsókn um leyfi fyrir viðkomandi stafvarpa þarf að liggja fyrir hjá Póst og Fjarskiptastofnun. En þrátt fyrir þetta vesen þá tryggja W2 stafvarpar mun meiri drægni en W1 sem þó skipta sköpum til að tryggja öryggt samband t.d. í gegnum handstöð eða á slæmum stöðum.

Ég vona að þessi pistill aðstoði þá sem hafa í hug að koma upp APRS stafvarpa sem og þá sem langar að kynnast APRS betur.

Hægt er að finna okkur á APRS-TF hópnum á Facebook eða senda mér tölvupóst á samuel@ulfr.net fyrir frekari upplýsingar.

 

 

 

Posted in Almennt, Electronics, Radio | Tagged , , , | Leave a comment

Working with the Nextion HMI Display

Lately I’ve been playing around with the Nextion HMI 2.8″ display from Itead studios. If you can get past the chinglish in their documentation it can be pretty fun and interesting little display. It provides RS232 at TTL for communication between a MCU and the display. There are some quirks, as we will see.

The editor software for the display only runs on windows, and is very limited and somewhat confusing. Writing to the display can be done in two ways, direct RS232 to the display (which according to some forum posts, can be rather tedious process) or upload to the display via µSD card.

Since I have a mac I use Windows 10 virtual machine for editing the display layout and then upload to the display via µSD card. Annoyingly enough, mac for some reason always creates ._NameOfFile.tft when uploading to the µSD card, apparently it’s something for spotligh for search indexing. This drives the display mad, and it took quite a while for me to realise what was going on when the display complained about multiple .tft files on the card. So, I went through terminal, navigated to the root folder of the card and just deleted that file… You can see where I’m going with this, it’s pretty time consuming when you are constantly updating the layout. So, I wrote a short script to handle this stuff for me. It’s pretty savage but pretty neat.

#!/bin/bash/

/bin/df -h | grep K-30

/bin/cp /Users/username/path/to/HMIfile.tft /Volumes/YourSDCard

/bin/rm /Volumes/YourSDCard/._HMIfile.tft

/usr/sbin/diskutil unmount /Volumes/YourSDCard/

echo ‘Success’

Could use some improvement, but it works and saves time which can be used for something more important, like petting my cats.

The HMI display spits out hex code for push actions, which makes it pretty easy to read whatever is coming from it, for example if you want  a button to let’s say, turn on a LED on an Arduino. But timing is critical, and especially if you are not using interrupts on the AVR so don’t let your loop do too much apart from just waiting for serial data coming from the display. Since I’m playing a lot with Arduino Nanos, I want to use software serial for the HMI, and use the primary serial for debugging and uploading sketches. Here’s my code snippet of how I read the data from the display:

 // We add the library software serial

#include <SoftwareSerial.h>

#define SERIAL_BAUD_RATE

#define LED_PIN 13 // Our LED is on pin 13 (default on Arduino nano, uno etc)

SoftwareSerial HMISerial(10,11); // connects to the serial of the HMI, TX, RX.

bool HMIcommand = false;

byte HMIbuffer[10]; // buffer for bytes coming from HMI.

int HMIbytes = 0;

int HMIendcount = 0;

//We wait for a specific hex string from the display to turn the LED on or off

byte switch_led_state[7] = {0x65,0x01,0x01,0x01,0xFF,0xFF,0xFF};

byte led_state =0; // Zero is off, so that’s how we start.

void setup()

{

Serial.begin(SERIAL_BAUD_RATE);

HMISerial.begin(SERIAL_BAUD_RATE);

}

void loop()

{

if (HMISerial.available())

{

byte inbyte;

inbyte = HMISerial.read();

//Serial.println(inbyte); print inbyte for debug purposes

if (inbyte == 0xFF)

{

HMIendcount++;

if (HMIendcount == 3)

{

HMIcommand = true;

HMIendcount = 0;

}

}

else

{

HMIendcount = 0;

}

HMIbuffer[HMIbytes] = inbyte;

HMIbytes++;

//Serial.println(“Loop ran again”); for debugging

}

// Process HMI data when they have been completely received and print them to the Serial interface

if(HMIcommand==true)

{

// For debugging purposes, shows what HMIbytes includes and the hex string from the HMI

/*

Serial.println(HMIbytes);

for (int x = 0; x < HMIbytes; x++)

{

Serial.print(HMIbuffer[x],HEX); // For debugging purposes

if(HMIbuffer[x] == 0x65)

Serial.print(” “);

}

Serial.println(“”);

*/

// compare arrays and do stuff – Here we check for the right hex value that changes the state of the LED.

int allMatch = 1;

for (int i = 0; i < HMIbytes; i++)

{

if (HMIbuffer[i] != switch_led_state[i])

{

allMatch = 0;

break; //If there’s a mismatch we just break out of the loop.

}

}

if(allMatch == 1)

{

Serial.println(“\nSwitch LED state\n”);

if(led_state  < 1)

{

digitalWrite(LED_PIN,HIGH);

led_state = 1; // We set the led_state to 1 so the program is aware that the LED is turned on.

}

else

digitalWrite(LED_PIN,LOW);

led_state = 0; // We set it to 0 so we know it’s off.

}

So that program should turn on and off the LED depending on the LED’s state and whether we are pushing the button or not. Let us break that down a bit to understand what we are doing. Most of these things should be pretty much explain them selves, so let us look at the interesting bits.

The HMI display ends all it’s hex strings with 0xFF 0xFF 0xFF. So whenever we see those three sisters, we know that the display has stopped sending us something and whatever comes next is a new event.

bool HMIcommand = false;

byte HMIbuffer[10]; // buffer for bytes coming from HMI.

int HMIbytes = 0;

int HMIendcount = 0;

HMIcommand is basically used to let us know whether we’ve received those three 0xFFs or not. HMIbuffer contains the string from the display and HMIbytes would be each byte that the display sends. Note that 0xFF is one byte, or 1111 1111 in binary, or 255 in decimal, so it fits nicely in our byte array of 7 bytes. Ie. each row in that array is a byte in size.

//We wait for a specific hex string from the display to turn the LED on or off

byte switch_led_state[7] = {0x65,0x01,0x01,0x01,0xFF,0xFF,0xFF};

byte led_state =0; // Zero is off, so that’s how we start.

The string of hex values we’re looking for is 0x65,0x01,0x01,0x01,0xFF,0xFF,0xFF. 0x65 is a touch event. First 0x01 is the page it’s happening at on the HMI. Second 0x01 is the ID of the button that is being pressed. The third is a touch event, we’ll not dig into that now. And then come the three 0xFF.

void setup()

{

Serial.begin(SERIAL_BAUD_RATE);

HMISerial.begin(SERIAL_BAUD_RATE);

}

We start both of the Serial ports, former for debugging, latter for the HMI serial port. Note that the display runs at 9600baud by default.

void loop()

{

if (HMISerial.available())

{

byte inbyte;

inbyte = HMISerial.read();

//Serial.println(inbyte); print inbyte for debug purposes

if (inbyte == 0xFF)

{

HMIendcount++;

if (HMIendcount == 3)

{

HMIcommand = true;

HMIendcount = 0;

}

}

else

{

HMIendcount = 0;

}

        HMIbuffer[HMIbytes] = inbyte;

HMIbytes++;

//Serial.println(“Loop ran again”); for debugging

}

If the serial is available, we read what’s coming from it, and put that into the array HMIbuffer.

    // Process HMI data when they have been completely received and print them to the Serial interface

if(HMIcommand==true)

{

Here comes the HMIcommand == true, if the first loop filled up it’s buffer, defined by the three 0xFFs, we look into what data the array holds.

// For debugging purposes, shows what HMIbytes includes and the hex string from the HMI

/*

Serial.println(HMIbytes);

for (int x = 0; x < HMIbytes; x++)

{

Serial.print(HMIbuffer[x],HEX); // For debugging purposes

if(HMIbuffer[x] == 0x65)

Serial.print(” “);

}

Serial.println(“”);

*/

The debugging function prints out the received hex string.

        // compare arrays and do stuff – Here we check for the right hex value that changes the state of the LED.

int allMatch = 1;

for (int i = 0; i < HMIbytes; i++)

{

if (HMIbuffer[i] != switch_led_state[i])

{

allMatch = 0;

break; //If there’s a mismatch we just break out of the loop.

}

        }

Here we look at the HMIbuffer array and compare it to our own predefined array that contains only one matching hex string, which in turn changes the state of the LED.

        if(allMatch == 1)

If it matches, we print a message to the debug serial consol, and check the state of the LED.

        {

Serial.println(“\nSwitch LED state\n”);

if(led_state  < 1)

If the led_state variable is less than zero, we assume it’s 1 or higher, and turn on the LED.

            {

digitalWrite(LED_PIN,HIGH);

led_state = 1; // We set the led_state to 1 so the program is aware that the LED is turned on.

}

Otherwise, it’s not turned off and we turn it off.

            else

digitalWrite(LED_PIN,LOW);

led_state = 0; // We set it to 0 so we know it’s off.

}

 

So that’s it! A bit of code to play against the Nextion HMI display to get you started. Of course there are libraries from Nextion that makes it easier, but my experience with them has been rather bad, so I ended up with just playing with the raw hex values rather than the libraries.

 

Posted in Electronics, Mechatronics | Leave a comment