Monday, September 16, 2024

The 1.8" IPS Capacitive touch ESP32-S3 Round Display (JC3636W518C)


This display costs about $20.00 U.S. has an ESP32-S3. Generally the specs are QSPI IPS 360x360 1.8inch, 8M PSRAM, 16M Flash. It has a capacitive touch display, I2S digital microphone, I2S analog-to-digital conversion circuit, TF card interface.
The display is a ST77916 with a CST816 touch controller. At the time of this writing I've only found two display packages that work with this. LVGL and Arduino-GFX (The latest version 1.4.9 by Moononournation https://github.com/moononournation/Arduino_GFX).

Can be programmed using Arduino, and various other IDEs. (I've only tried Arduino so far)

It was apparently designed for AIDA64 as a 2nd display. The seller only provides a LVGL example.
Doesn't provide the firmware that is currently installed on it.

However there is a 1.8_demo.bin provided - this appears to be the original demo code that is installed.
It would be safe to say, they don't provide the source code to this demo. But the original demo can be reloaded if you want it back.

They do provide just enough information to get the display working using LVGL. 
Moononournation provides more examples found here:
https://github.com/moononournation/JC3636W518 I could really only get a couple to work, and one of those I had to modify the code to read the SD card. 
It appears to me (at least at the time of this writing) this is a work in progress.
But provides a nicer way to display pictures, and mpegs (off the SD card).

My next step will be to see if I can get MP3 to play, and use the on board microphone for something.

Below are some pictures of mine: (NOTE: I don't recommend opening this, I broke a small piece while attempting to get the cover off. There is heat tape and a temperature sensor (I think), I got mine back together, but it's night quite as tight as it was and it does seem like it gets a little hotter then it did)

Thursday, May 23, 2024

Microcenter Inland MK-87 TKL Mechanical Gaming Keyboard a good keyboard?

It's been a while since I made any type of blog post, and this one is being made on my new MK-87 TKL Inland mechanical keyboard.
A little background, over the past month or so friends of mine have been talking about their mechanical keyboards. Features, and other things about them. Yes I said keyboards, they have spent upwards of 200 per keyboard, and own three or four, they buy replacement keycaps, replace the switches, make macros, change the LED patterns. And just in generally really really like the keyboards.
Last week I finally broke down, and started to look for one - I found a few Keychron keyboards on eBay for a reason price. See for the most part I'm cheap, and I don't want to spend much on a keyboard even thou it is something that I use all the time. $20 to $30 seems like an ok price, with $30 certainly being on the high side for me. (*Spoiler*) it turns out, I probably should have spend a little more and got something a little different.
Enter the Inland MK-87 TKL keyboard, while I was looking on eBay, I came across an Inland keyboard - it looked ok(ish), the seller wanted almost retail for it thou. So I looked at the Microcenter website, turns out a brand new keyboard was cheaper then what the seller on eBay wanted. I know shocker, sellers are always going to try to get more then they should.
The keyboard is actually an ok keyboard, it works surprisingly well for a $30.00 mechanical keyboard. It comes with brown switches, that are NOT hot swapable. The case is (I believe ABS), but feels good. And has a good enough weight to it. It doesn't slide around while typing, the keys feel good in my fingers, I am still getting a little use to them, but I've only had the keyboard for two days.
Unfortuntally I knew the day I got it, that I should have spend a little extra and got one of the used Keychron keyboards I had found. Yes, you can find pre-owned Keychron keyboards on eBay for a decent price.
I do feel like I type faster on my old membrane keyboard, but the online typing tests don't support that. In truth I type about the same on both keyboards. I have noticed I error a bit more on this keyboard. But I think that has more to do with how the keys are spaced and how I'm use to the other keyboard. And not anything this keyboard is doing.
This keyboard has "RGB" lighting, which is true and false. It has multi-color LEDs, each in a zone, so you have a "GREEN", "ORANGE/YELLOW", "RED(ISH)", "BLUE" and "PURPLE" Zone. It has I think 10 different animations, some of them are pretty good, others not so much. The speed of the animations can be changed, but I don't really see much point to that. The brightness of the LEDs can also be changed. They are top lighted LEDs, I've read various reason why this wasn't a great choice, but I think it's fine with the keycaps that are currently on it. Speaking of the keycaps - the font used on them is a little strange, I'm not really sure what font it is, mostly I notice the 4, 6, 8,9, 0, @, #, % and the Q, R O, P A, D, B all have little gaps in them. It's fine, just weird to me, and something I'm sure I would get use too.
OH I forgot the LED under the "R" key is barely visable, I'm not sure what is causing it - but it looks like the led maybe facing the wrong direction. I don't mean in the wrong place (Like it is at the top like all the other LEDs) I mean it kind of looks like it might be upside down. I need to explore this later if I decide to keep the keyboard. Or I just need to live with it like this. (Picture below)
The user guide, which is short and too the point, included with the keyboard does say you can program macros into F1 - F12 keys. I haven't tried that yet but I'm sure it will work fine.
The only weird quirk is that sometimes there seems to be latancy between a key being pressed and the input on the computer. I really only have noticed this when you do a double space, sometimes the next character doesn't register. Is this a problem? Well, yeah kind of. When you are typinging and use a double space, you think you hit a letter, but it doesn't register that is a problem. At first I thought maybe it had something to do with the animation pattern of the LEDs, so I turned them off, and it didn't change anything.
That is really the only "problem" that I've seen so far with the keyboard. And I guess if maybe you might get use to it, but it shouldn't do that.
The brown switches have a nice tactile feel to them, and there is a noticable "clunk" it's not really a "click" - but it's close. I have noticed that some of the letter will register quicker then others, so maybe not the best switches used? I mean after all this is a $30.00 keyboard.
The keyboard uses a SINO WEALTH controller, and from my understanding is either a 8051 or emulating a 8051. There are a couple of github projects that will let you flash new firmware. BUT I wouldn't do that with this keyboard, first you have no idea how the controller is hooked up to the leds, or how it is scanning the keyboard. Maybe you could dump the current firmware and figure out that information. It's my understanding Sino makes the controller, but OEMs can wire it however they want, the controller IDs the same for every keyboard "Device 020: ID 258a:002a SINO WEALTH Gaming KB" so it is really impossiable to tell what keyboard you might be using. So using something like OPENRGB or Via would NOT be possiable or advisable for this keyboard. As a number of people have reported a bricked keyboard after using OPENRGB.
I actually tried OpenRGB before I knew this, lucky for me OpenRGB took support for Sino controllers out of it's scan, so, that probably prevented problems.
In short, this is an ok basic mechanical keyboard, I would say it's ok entry to the world - but if you have the money get a Keychron. You can find Keychron keyboard for reasonable prices. As far as the switches goes, every one has a switch they like, the fact that I like brown or blue switches, was a bonus for me with this keyboard. But not being able to swap switches easy was kind of a bummer. I have to remember this is an entry level keyboard. And not all Keychron keyboards have hot swappable switches either. For just a little more then the cost of a membrane keyboard, this is an okay keyboard. It's a good replacement if you need a new keyboard.
It is probably a gateway to other mechanical keyboards. As I've said I've have the keyboard for less then 2 days, and already know that I should have spent a little more for a slightly better keyboard.
I'm now looking at getting a Keychron C3 Pro QMK/VIA with brown switches and hot swappable keys for $46. Which is probably what I should have done in the first place.

Monday, November 7, 2022

Using Keyoxide for Mastodon Proof of who you are.

 I'm writing this because I found the documentation to be a little confusing, the process turns out to be not so bad.  So this is an attempt to clarify some of the things I was having problems with. Hopefully it doesn't make matters worse.


My system (why is this important, it will become clear below).  My machine is an AMD Ryzen 5 5625U, with 8gb ram, and 512gb SSD running Linux Mint 21 (Mate). The machine in itself isn't that important, thou if you need to generate a new key pair it might take a few minutes on a older (slower) machine. The important part is I use Linux (Mint is based off Ubuntu so Debian based, this is important because GPG comes preinstalled.)

So if you have Windows - you'll most likely need to install GPG which is beyond the scope of this posting.  https://gnupg.org/download/  ** Be sure to check the download signature.
*** I think the commands will all be the same no mater which version of GPG you are using.

To start with the documentation is using the command line (CLI), don't worry if you aren't familiar with the CLI, everything you'll be doing is pretty easy. PS in Linux the command line is called Terminal.

The other thing to note is I'm using a signature proof, which are marked as being experimental feature. 

I'll be using the documentation found at: https://docs.keyoxide.org

1) The first thing you need to generate a key pair - this step can be skipped if you already have one (Goto step 2). The keyoxide docs are pretty good for this step, and I don't think I can add anything.  But you will want to make a note of your fingerprint (The public fingerprint, NOT the private fingerprint) 

https://docs.keyoxide.org/using-cryptography/openpgp-gnupg/

2) You need to upload your public key to the keys.openpgp.org keyserver. And again the above URL walks you though that pretty well. The only thing I can add here is even if you already have a key pair you'll probably want to make sure it's on the openpgp.org keyserver because unfortunately it's a bit hit or miss if a keyserver shares with other keyservers.

 ** I didn't use the WKD server option. There is also some other information on this page that tells how to sign a document, and how to verify a signature. All is good to know if you are not familiar with GPG/PGP.

3) Next We need to create a signature file that will become part of the proof for Mastodon - this is where I started to have some confusion so I'll try my best to make it a bit easier. https://docs.keyoxide.org/signature-profiles/overview/

   a) Using GnuPG (GPG) we need to create a profile file, this is just a text file that we will sign with the key pair we just created.  The most important thing is using the correct syntax for the PROOF line. (This same file if I understand correctly can be used to provide proofs for other sites that Keyoxide supports. We are currently interested in Mastodon, so let's just start there. Other service providers can be found on the left side of the website at the bottom of the documentation)

  b) Create a file that looks like this:

Hey There Here's a signature profile with proof I am @kd8bxp@mastodon.radio
verify this profile at https://keyoxide.org/sig

proof=https://mastodon.radio/@kd8bxp

     Change my username to your own of course, it wouldn't do much good to try to verify you are me. Save the file with a name somewhere that you can find it. Next we are going to sign this file.

  c) It's simple, you just need to use the command: gpg -u EMAIL_ADDRESS --clear-sign FILENAME 
Where EMAIL_ADDRESS is the email address you used when you created your key pair, and FILENAME is the name of the file you just created.  This will create another file with the .asc file extension, it's clear text. This will be the file that you will share with others that will end up becoming the proof after they verify the signature of the file.  I decided to share this with a github gist. https://gist.github.com/kd8bxp/bfd9d9b1379cfc42e96d0c1e0dbe55ea

* There is no clear way that you should share the file, email it, github, a link to it in a post?  The person you share it will need to goto the https://keyoxide.org/sig site and copy and paste it there to verify you are your.
** IF you add or change this file, you will need to sign it again, and upload the new file (or share the new file making sure you also delete the old file).
*** If you move from this instance of mastodon to another, you'll want to delete the current line and replace it with your new username/instance  - and remember to sign it again, ect.


We are almost done....

4) Adding a link to your fingerprint (created above) to mastodon.radio https://docs.keyoxide.org/service-providers/mastodon/ (This is the step that I got the most confused about - turns out the simplest way (URL) is easy, thou I wonder if I shouldn't be hashing the URI which I didn't understand how to do at all if I'm honest here)

   a) log in to your Mastodon instance (mastodon.radio) click on Edit profile
   b) You will need to add a line to your Profile metadata

   c) After you label one of the metadata areas, just add the URL  https://keyoxide.org/FINGERPRINT  to the content side.  Where FINGERPRINT is the key pair FINGERPRINT from earlier. 

That's it, you should be able to go to https://keyoxide.org/sig copy the contents of your proof file into the site, and click on generate profile - if everything worked you should see a green check next to your mastodon proof.

Hopefully this helps someone else who was having a hard time setting this up.


keybase

================================================================== https://keybase.io/kd8bxp -------------------------------------------------------------------- I hereby claim: * I am an admin of https://kd8bxp.blogspot.com * I am kd8bxp (https://keybase.io/kd8bxp) on keybase. * I have a public key ASDmzCZJug4yHxlceM_8A1wFJ1rOx4Ppj6drMOVkkCT8bAo To do so, I am signing this object: { "body": { "key": { "eldest_kid": "0101273e3d5ba8114ef784c369a29f12dc463e2f7567102ce2e6b69a350d12250d760a", "host": "keybase.io", "kid": "0120e6cc2649ba0e321f195c78cffc035c05275acec783e98fa76b30e5649024fc6c0a", "uid": "b4ecb3e33f2fa9c54e6c94b6e1aede19", "username": "kd8bxp" }, "merkle_root": { "ctime": 1667857200, "hash": "2138c546f57ca2ac5538827a33cb13e3480b18648a494809a892567a206ecede72d4432ff610104895ebb7aee572b75755d4e51b7b2a1f6a48256898ffe88ece", "hash_meta": "d9c80f31b813fd0c6a3d0a8b9d508a0dd213178afcdc84d725bc2eb45c3226b4", "seqno": 23507539 }, "service": { "entropy": "eX2THmJuI1Su4hhKoV9zXfSL", "hostname": "kd8bxp.blogspot.com", "protocol": "https:" }, "type": "web_service_binding", "version": 2 }, "client": { "name": "keybase.io go client", "version": "6.0.2" }, "ctime": 1667857209, "expire_in": 504576000, "prev": "1df5c44958883338cd511509872c0b8c14060352c4cc97135bd1f209be82ae44", "seqno": 56, "tag": "signature" } which yields the signature: hKRib2R5hqhkZXRhY2hlZMOpaGFzaF90eXBlCqNrZXnEIwEg5swmSboOMh8ZXHjP/ANcBSdazseD6Y+nazDlZJAk/GwKp3BheWxvYWTESpcCOMQgHfXESViIMzjNURUJhywLjBQGA1LEzJcTW9HyCb6CrkTEII99sks8b3LVyoL1ULq5B3Lltto/o9+XzvnjdWV6BL0MAgHCo3NpZ8RA6RntQEWDxwZnBiqOtSrGbikYkTfZe8lX5ex+tFsh/9PKlkizJfRF/mLajoYZM+Z0f7coqVo0cMThKBDZ7kTBBqhzaWdfdHlwZSCkaGFzaIKkdHlwZQildmFsdWXEIKJ9yvFk1ennOp+qVcfxoH8CtLhegMz3/eoCeLeJKlJTo3RhZ80CAqd2ZXJzaW9uAQ== And finally, I am proving ownership of this host by posting or appending to this document. View my publicly-auditable identity here: https://keybase.io/kd8bxp ==================================================================

Sunday, September 13, 2020

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. 


Tuesday, December 18, 2018

A 100 meter lidar (?) Maybe not.....

100 Meter LiDAR Range Sensor
Found this unit on Aliexpress, for around $32 dollars, it was probably used as an electronic tape measure. The thing that peaked my interesting was the 100 meter range (328 feet or so). It is easy to use, and seems to work well, but so far I've not gotten anywhere close to the 328 feet. (32.8 feet is about the best I've seen so far)
Could this be a miss print on the listing, or could I just be using this wrong (?) ......
Well either way, I've set this up to work with an Arduino Uno - so far I'm just displaying the distance on a DF Robot 1602 LCD/w buttons.
Laser Type: 635nm, 1 mw (red)
Range: 0.02 to 100 meters
Typical accuracy: +/- 2mm (0 to 40, indoor 20 meters white walls; through correction can be up to +/- 1.5mm)

The laser can be turned on or off (assuming for aiming reasons), reads can be “automatic”, fast (less accuracy), and slow (more accuracy) - “automatic” appears to be about medium speed.
The laser can also display it’s temperature and voltage levels. The output of the sensor is in the format of a String, a typical reading may look something like this:
“12.345m,0079” which tells the distance, and signal quality.  Signal quality a lower number is better. This is good for display, and easy to use for display, but it’s a problem if we need to compare the numbers, or if we are using this on a robot and need the robot to stop at a distance.
Luckily - there is a way to remove the unwanted information from a string, and turn that string into a float - it’s not pretty, and a lot of code to do it, but it can be done.
In my demo, I’ve converted the distance from meters to feet to cm to inches. I’ve dropped the signal quality - but it can be pulled out and used as well.
The demo, will display if the laser is on, or off, the temperature and voltages (default temperature is Celsius, and I convert it to Fahrenheit), formatted for the display I am using.
I’ve setup 5 buttons, one for normal reading, one for fast, one for slow - one will toggle the laser on or off, and one will display voltage, temperature.
An expanded demo would be to use this on a robot for distance/obstacle avoidance.
(under my less than scientific tests, I’ve only been able to get a reading of 32.x feet or about 10 meters - anything greater than 32 feet gives either a reading that is just wrong, or an error. Is it possible that I have a bad unit, or that it really is 10 meters not 100 meters (which would mean it was listed wrong to start with)? )

Wednesday, October 10, 2018

Merge two GIT repositories to ONE.

Recently I wanted to merge two GIT repositories into one.  The main reason for this was the two projects were different, but closely related, sharing much of the same code.  And I just thought it would be easier if everything was together.

So I did what any normal person does, I googled it.  Turned out this is easier to do that I thought it would be - the results are easy to find on google - but I thought I'd share my use case - not only might it help someone else - But it will help me when I want to do this again - I willn't have to search, I can just look at my blog :-)

This posting on stackoverflow asks the question perfect:
https://stackoverflow.com/questions/1425892/how-do-you-merge-two-git-repositories

Question:
"Consider the following scenario:
I have developed a small experimental project A in its own Git repo. It has now matured, and I'd like A to be part of larger project B, which has its own big repository. I'd now like to add A as a subdirectory of B.
How do I merge A into B, without losing history on any side?"
The Best Answer:
If you want to merge project-a into project-b:
cd path/to/project-b git remote add projectgit remote add project-a path/to/project-a git fetch projectgit fetch project-a git merge
git merge --allow-unrelated-histories project-a/master # or whichever branch you want to merge git remote remove project-a 
This method worked pretty well for me, it's shorter and in my opinion a lot cleaner.
Note: The --allow-unrelated-histories parameter only exists since git >= 2.9. See Git - git merge Documentation / --allow-unrelated-histories
This also worked pretty well in my case, I ran into one conflict - so off to google again to find how to resolve that (again, GIT makes it pretty easy to deal with the conflict)
https://help.github.com/articles/resolving-a-merge-conflict-using-the-command-line/

This needs to be read - but the basics of it the arrows in the file show where the conflict is, and from which branch the conflict came from.  And the equals is the dividing point.
So you might see something like
If you have questions, please
<<<<<<< HEAD
open an issue
=======
ask your question in IRC.
>>>>>>> branch-a

Decide if you want to keep only your branch's changes, keep only the other branch's changes, or make a brand new change, which may incorporate changes from both branches. Delete the conflict markers <<<<<<<=======>>>>>>> and make the changes you want in the final merge. In this example, both changes are incorporated into the final merge:
If you have questions, please open an issue or ask in our IRC channel if it's more urgent.
Add or stage your changes: git add *
and commit the changes with a comment:
git commit -m "resolved merge conflict"

There are other cases covered by the github help competing changes to a file that deal with complete file conflicts