[EN] Unlock the 108-136 MHz on Uniden UBC 60XLT-2

Uniden/Bearcat UBC60XLT-2 is a 80 channels/8 band radio scanner on 66-512 MHz range.

The frequency coverage is not continuous from 66 MHz to 512 MHz, and is divided in 8 bands (EU version):

66-88 MHz
137-144 MHz
144-148 MHz
148-174 MHz
406-420 MHz
420-450 MHz
450-470 MHz
470-512 MHz

If you try to store an out of range frequency, the firmware returns “Error” on the display.

The heart of this scanner is an UC2345 proprietary microprocessor (labeled IC203 on the PCB). By grounding the 80th PIN it is possible to unlock 108 MHz – 136.9750 MHz frequencies.

Unlock the 108-136 MHz on Uniden UBC 60XLT-2 by grounding 80th pin of the IC203

[EN] 3D Printer PWM/TTL Laser Adapter

This circuit needs to adapt a PWM/TTL laser module to a 3D printer using a cooling fan output.
You need to use a laser which has the PWM/TTL control on a port different from the one used for the power.

You can turn the laser ON with GCODE command M106 Sxxx (where xxx is an integer number from 0 and 255) and the laser OFF with M107

For example:

M106 S127 ; This line turns the laser ON to half power (50%)
M106 S255 ; This line turns the laser ON to full power (100%)
M107 ; This line turns the laser OFF
M106 S0 ; This line turns the laser OFF too (0%)

Through the use of JP1 jumper you can switch from Laser to Fan, so you don’t need to detach this interface to use your printer normally.

12V or 24V printer

If your FAN runs at 24V R1 must be 2.2KOhm, if it runs at 12V R1 must be 1.1KOhm.

Note that JST (white) connectors are rotated to respect Creality 3D Ender 3 PRO polarity, so if your printer has inverted polarity rotate the JST connectors accordingly.

GitHub Repository

https://github.com/siddolo/3Dprinter-laser

[EN] Drive a relay with an USB-to-UART interface

Versione italiana sul sito dell’associazione LILIS.

The RS232 standard implements an hardware flow control mechanism. While TxD and RxD pins are used to send and receive data, DCD, DTR, DSR, RTS, CTS and RI allow devices which support hardware control flow to maintain a reliable data connection between a transmitter and a receiver.

Signal Pin  Pin  Direction  Full
Name   (25) (9)  (computer) Name
-----  ---  ---  ---------  -----
FG      1    -      -       Frame Ground
TxD     2    3      out     Transmit Data
RxD     3    2      in      Receive  Data
RTS     4    7      out     Request To Send
CTS     5    8      in      Clear To Send
DSR     6    6      in      Data Set Ready
GND     7    5      -       Signal Ground
DCD     8    1      in      Data Carrier Detect
DTR    20    4      out     Data Terminal Ready
RI     22    9      in      Ring Indicator

From the computer side the output pins are: RTS, DTR and obviously TxD.

Both RTS and DTR pins are usable to our scope, I have chosen the RTS one.

The RS-232 standard defines the voltage levels that correspond to the logical “one” in the range of +3V to +15V and the logical “zero” in the range of -15V and -3V but, through a TTL/CMOS converter, we can use 0V and +3.3V/+5V.
If you want to use a real RS232 port (DB9 connector) you can use the MAX232 IC to use a TTL or CMOS voltage level.

In a modern computer without a RS232 port you can use a cheap USB/TTL-232 interface like this, which already has the TTL voltage values.

Not all of these interfaces have all control flow pins so, if you want to buy the new one, check if RTS and/or DTR are present. On my old USB-to-TTL232 interface neither of those was there, but it uses a PL2303 driver that exposes RTS on pin 3 and DTR on pin 2 so I had to solder a wire directly on IC pin.

The output of RTS (or DTR) pin needs to be connected to the Base of a BJT transistor that controls the current flow through a relay:

If you don’t want to build that part you can use one of these: https://amzn.to/2QDpRQF or https://amzn.to/2QycYHM.

This is the code to SET the RTS pin:

#include <fcntl.h>
#include <sys/ioctl.h>
#define PORT "/dev/ttyUSB0"
main() {
  int fd;
  fd = open(PORT, O_RDWR | O_NOCTTY);
  ioctl(fd, TIOCMBIS, TIOCM_RTS);
  close(fd);
}

and to CLEAR the RTS pin:

#include <fcntl.h>
#include <sys/ioctl.h>
#define PORT "/dev/ttyUSB0"
main() {
  int fd;
  fd = open(PORT, O_RDWR | O_NOCTTY);
  ioctl(fd, TIOCMBIC, TIOCM_RTS);
  close(fd);
}

To use DTR instead of RTS change TIOCM_RTS to TIOCM_DTR.

Compile it with gcc:

gcc set-rts.c -o set-rts

or run in with tcc:

tcc -run set-rts.c

Here’s mine:

[EN] Decoding Oregon Scientific RTGN129 with RTL-SDR [PART 1]

Oregon Scientific RTGN129 is a remote temperature and humidity sensor designed to be used with Oregon’s PRYSMA series stations.
It uses the standard 433MHz band so we can tune our RTL-SDR USB dongle to receive their signal. But how to decode it?

There are plenty of documentation about decoding Oregon’s devices, and Benjamin Larsson’s rtl_433 tool may decode many of 433.92MHz devices but, unfortunately, it didn’t support the RTGN129.

This is the great opportunity to skill myself in reverse-engineering of an “unknown” signal, so I decided to implement it into rtl_433 (Merged pull request: https://github.com/merbanan/rtl_433/pull/634).

From RTGN129 datasheet we have the confirmation that this device transmits at 433MHz.

Oregon uses several protocol versions (v1.0, v2.1, v3.0) so, first of all, we need to discover if our RTGN129 uses one of these. Protocol documentation are here and here.

Instead of using directly rtl_433 in analyze mode (-a flag), we’ll pretend it does not exist and we’ll go down to low level just for fun. A sort of simulated black-box approach.

There are several tools in the wild to analyze the radio signal from an RTL dongle, but one of the best, IMHO, is baudline.

You can use it in the “hacker’s way”, for example:

FR="433.944e6"; SR="2.5e6"; \
rtl_fm -f $FR -s $SR -g 30 -M am | \
baudline -reset -flipcomplex -samplerate $SR \
-basefrequency $FR -channels 2 -quadrature \
-format u8 -fftsize 2048 -stdin

First of all, we need to find the right PPM value to use in the next commands to calibrate our dongle.

rtl_test -p

So we can find the exact frequency of RTGN129 starting from the 433.92MHz:

FR="433.92e6"; SR="2.5e6"; \
rtl_sdr -p 130 -f $FR -s $SR -g 30 - | \
baudline -reset -flipcomplex -samplerate $SR \
-basefrequency $FR -channels 2 -quadrature \
-format u8 -fftsize 2048 -stdin

Where -p is our PPM, -f is the tuned frequency, -s is the sample rate, and -g is the gain (0 for auto). The last “-” before the pipe stands for “stdout”.
433.92e6 stands for 433.92 * 10^6 so 433.92MHz that is more readable than 433920000.

The above command shows you the baudline window. When you see the burst passing in the spectrogram press “pause” on your keyboard, center the signal in the spectrogram area (green background) with the mouse, than center it in the spectrum analyzer (black background) and read the exact frequency on the bottom-right area: 433.95Mhz

Right click on the spectrogram area, then select display, then click wafeform. Now we can see the waveform of the signal in the time domain. To zoom in/out you may use ALT + right and left arrows.

Navigating the waveform we notice that, when the signal is present, the frequency and the amplitude stills the same, and there are silence between two signal, just like in the On-Off Keying!

Basic digital modulation formats:

Now we use “rtl_fm” instead of “rtl_sdr” to demodulate the signal using AM demodulator:

FR="433.95e6"; SR="2.5e6"; \
rtl_fm -f $FR -s $SR -g 30 -M am | \
baudline -reset -flipcomplex -samplerate $SR \
-basefrequency $FR -channels 2 -quadrature \
-format u8 -fftsize 2048 -stdin

and finally visualize the demodulated bits!

If we decode it as “Manchester code” we read:

Instead of frustrating us overlaying red lines in gimp, as I did with the above image, we can use Universal Radio Hacker to decode the stream!

(to be continued …)