sunnuntai 27. toukokuuta 2018

Receiving Aalto-1 satellite with RTL-SDR

I recently bought an RTL-SDR dongle mostly to try to receive weather satellitse (see e.g. this guide for guide on how, and this nice software for more info), but also to experiment with receiving other kinds of radio communications.

While browsing the net for information about different satellites, antennas, etc I ended up to a Finnish page about receiving Aalto-1 satellite. The satellite is built by students at a Finnish Aalto university, hence the name. The satellite information is freely available and some parts of the communication is easy to receive.

The easiest part, the only part I got, is a morse code of the satellite callsign, AALTO1. It is transmitted every 3 minutes at 437.220 MHz frequency and it lasts for 6 seconds. The modulation is constant wave.

I used a simple V-dipole antenna which I mainly use for weather satellites at 137...138 MHz. I pointed it to south (since from there the satellite crosses the sky at my location) with as clear as possible view to sky. The antenna is most likely not optimal, but seemed to work somehow.


I used gpredict to see when the Aalto-1 satellite would cross the sky, but it is possible to track it online, too. When the time was, I tuned the RTL-SDR dongle to 437.220 MHz, and set it to record the baseband. About when the satellite was directly above, I got the above signal! (The vertical dashed line in the middle). Success! Looks very similar to the picture in the other blog, but not as clear due to lower signal level.

A bit later I also received next beacon with better signal quality, but unfortunately I was not recording at this time. Picture of the second beacon (beginning was already off the screen):
After recording was done, I reloaded the IQ wav file back to RTL-SDR using the FilePlayer plugin and searched for the signal. After finding it, I set CW modulation with 500 Hz bandwidth and centered the tuner to the signal. The signal frequency was a bit off, partly due to the low quality oscillator of the RTL-SDR dongle, partly due to doppler effect as the satellite flies so fast over the sky. I tuned about to the center of the beacon.

I played the demodulated signal to Audacity via a virtual audio cable. The signal indeed sounds like morse code an parsing the first 5 characters, they are .- .- .-.. - ---, which stands for AALTO. The last character in this recording is bad, but from the screenshot of second beacon, it can be barely seen that it is .---- which stands for 1.

Here is a link to the CW demodulated audio signal from the first recording. The doppler shift can clearly be heard in the signal!

sunnuntai 31. joulukuuta 2017

Rooting LG Leon with Android 6.0

Disclaimer: This post is for information purposes only. It is not a guide but a log of what I did to root the phone. Rooting may result in loss of data or brick your device, everything is done at your own risk. I'm not a developer, I do not know the details of how rooting works, and I cannot help if something goes wrong during the process.

Introduction

I have a LG Leon phone, which is a low-end Android phone. It has limited storage space and also other limitations, like not being able to store applications on SD card. It constantly runs out of storage space so I wanted to root the device to be able to delete non important stock apps and also to do other things, like maybe move apps from internal storage to SD card.
The phone model is LG-H340n, software versions Android 6.0, V20a-EUR-XX  .

Rooting process

I found a forum thread describing the process for this phone and Android version (post here). Other guides were for earlier Android versions or using Kingroot. I've heard some bad words about Kingroot so I didn't want to use that, this new guide was with TWRP and SuperSU which were familiar to me. This process is a copy of the guide with some changes I needed to do to get it to work. Thanks to users hokutojm and Wolftein for the process.

Prerequirements

  1. Back'd-up everything, since failing the process may result in factory result or bricked device
  2. Enabled developer mode by tapping Settings -> General -> About phone -> Software Info -> Build number about 8 times. 
  3. Now in Settings -> General -> Developer options checked Enable OEM unlock and USB debugging
  4. Connected the phone to computer with USB cable, then tapped the notification for more USB options. From the USB PC connection screen selected the 3 dot menu and Install PC drivers. This made the phone to show up as a disc drive in Windows My Computer. Double clicking on that installed the LG USB drivers.
  5. Python is needed, I had 2.7 already installed so I used that and it worked.
  6. Downloaded LGLAF python scripts and unzipped them to C:\LG\. I had to modify the lglaf.py script according to this bug report to make it work, otherwise it would hang on read. I also replaced name.endswith('ANDNETDIAG1'): with name.endswith('DIAG1'): in lglaf.py.
  7. Downloaded TWRP recovery with the correct partition size (Recovery.bin wiped out + TWRP 3.1.0). I used this file since according to the posts it works better than using the stock TWRP binary from the site or from the download site. Put the img file in the same folder where lglaf was unzipped.
  8. Downloaded Custom Android Bootloader, more info in this thread. Put the aboot.bin to same folder where lglaf was unzipped.
  9. Downloaded latest SuperSU and copied the zip file to the root folder of an SD card. I did not use the same SD card which was used for backup just to be sure that the data was safe. Put the SD card to the phone.

 

 Dangerous parts

  1. Turned off the phone. Then while pressing the Volume up button connected the phone to PC with USB cable. Kept the Volume up pressed until Firmware Update screen showed up.
  2. Now in Windows' Command prompt (cmd) browsed to where lglaf was unzipped.
  3. First I tried running
    python partitions.py --debug –list
    This resulted in a long list of partition names and offsets, which indicated that the communication was working properly.
  4. Run following commands to dump the original partitions:
    python partitions.py --dump aboot.old aboot
    python partitions.py --dump recovery.old recovery
    Commands resulted in the script giving this kind of information on success:
    2017-12-30 22:15:26,241 partitions: INFO: Wrote 2096640 bytes to aboot.old
  5. Replace the partitions with the custom ones:
    python partitions.py --wipe recovery
    python partitions.py --restore twrp-3.1.0-0-c50.img recovery
    python partitions.py --wipe aboot
    python partitions.py --restore aboot.bin aboot
  6. Turned off the phone by running
     python lglaf.py --debug -c "!CTRL POFF"
    and then disconnecting the USB cable.
  7. Next step was to enter download mode again. It was VERY IMPORTANT to PREVENT THE PHONE FROM BOOTING. If it rebooted and started android, all the changes were reverted and continuing wiped the phone. This happened to me. So now back to download mode by pressing Volume up and connecting USB cable.
  8. Run
    python partitions.py --dump recovery.new recovery
    to dump the newly flashed recovery partition.
  9. Compared the recovery image the the flashed on with fc /b recovery.new twrp-3.1.0-0-c50.img The files must match, otherwise the flashing failed and continuing would result in factory reset. fc displayed
    Comparing files recovery.new and TWRP-3.1.0-0-C50.IMG
    FC: TWRP-3.1.0-0-C50.IMG longer than recovery.new

    which indicates that files are identical, except for length (I don't know why the length is different)
  10. Again turn off by running following command and disconnecting USB cable
    lglaf.py --debug -c "!CTRL POFF"
  11. Next up was booting into factory reset menu, failing this would revert all changes again. Factory reset menu was reached by powering up pressing Volume down and power button, and as soon as LG logo appeared, released the buttons and re-pressed them again until menu was displayed.
  12. In the menu factory reset was selected and confirmed, but instead of reset the TWRP would boot up.
  13. In TWRP I followed this guide to install SuperSU:
    1. Selected Allow modifications
    2. In TWRP ->  Advanced -> Terminal wrote the following command:
      echo "SYSTEMLESS=true" > /data/.supersu
    3.  In TWRP -> Advanced -> File manager checked that there was indeed .supersu file in /data/
    4. Installed SuperSU from memory card with TWRP -> Install and browsing to the external SD and selected the zip file. Confirmed flashing, wiped cache/dalvik and then rebooted. I opted not to install the applications, but I don't quite know what those were anyways...
  14. After the phone rebooted, I was root! Now just to restore backups since I first failed the procedure...

sunnuntai 6. elokuuta 2017

Using Wiimote as a lightgun in MAME

Last time I wrote about how to get Wiimote to work as a mouse pointer in X. After that, I started to wonder if I could also use the Wiimote as a light gun in emulators, especially in MAME. MAME has some nice arcade shooters, like Time crisis, which would be much more fun with a proper pointer.

It should be quite simple, since MAME supports mouse as a light gun out of the box. Or so I thought. It turns out, it isn't so simple after all. I found a blog post which explained how to do it, but I couldn't get it to work.

First, I use autodetection in X.org, so I don't have xorg.conf. Anyways, since I already got X to detect the wiimote, I didn't think it would be a problem.
Second, even though e.g. jstest-gtk displayed the joystick, I couldn't get MAME to see it. No joysticks no matter what I tried. Also as a mouse the Wiimote acted weird. In desktop all was good, but in MAME cursor just jiggled in bottom right corner.

Anyways, after 3 evenings of trying I got it to work. Here's how it went:

First I connected the wiimote:
$ sudo wminput -c ir_ptr A4:C1:E2:C4:DB:4F
Put Wiimote in discoverable mode now (press 1+2)...
Ready.

Even though the jstest-gtk and sdl-jstest both displayed the wiimote as joystick and operated properly, the sdl2-jstest did not work. I assume MAME uses sdl2, so that explais why MAME did not see the Wiimote either.
$ sdl2-jstest --list
No joysticks were found


Then I decided to try different approach. I added my user to the "input" group, so that it can read /dev/input/eventXX which is where the Wiimote data comes from:
$ sudo usermod -G input [user]

After that I used evtest to check that the Wiimote really works, and what the event device number is:
$ evtest
No device specified, trying to scan all of /dev/input/event*
Not running as root, no devices may be available.
Available devices:

...
/dev/input/event14:     Nintendo Wiimote
Select the device event number [0-14]: 14
Input driver version is 1.0.1
Input device ID: bus 0x5 vendor 0x1 product 0x1 version 0x4
Input device name: "Nintendo Wiimote"

...

I entered 14 to the prompt (the number after the Wiimote event), and checked that events are reported when pointing the wiimote to a candle and moving it around. The events look like random blocks in the terminal.

After verifying what the event device is (in this case /dev/input/event14) , I forced SDL to use that device as the joystick device with an environmental variable, and behold, the Wiimote was detected as a joystick:
$ SDL_JOYSTICK_DEVICE=/dev/input/event14 sdl2-jstest --list
Found 1 joystick(s)

Joystick Name:     'Nintendo Wiimote'

...

And also testing it with the sdl2-jstest now worked properly. Great!
$ SDL_JOYSTICK_DEVICE=/dev/input/event14 sdl2-jstest --test 0

Now it was time to test with MAME. But first I wanted to disable the mouse operation of Wiimote so that it would not interfere with the joystick operation. I did this by finding the Wiimote device id with xinput, and then disabling that device:
$ xinput list
| Virtual core pointer             id=2    [master pointer  (3)]
|   ↳ Virtual core XTEST pointer   id=4    [slave  pointer  (2)]
|   ↳ Nintendo Wiimote             id=13   [slave  pointer  (2)]
| Virtual core keyboard            id=3    [master keyboard (2)]
    ↳ Virtual core XTEST keyboard  id=5    [slave  keyboard (3)]


$ xinput disable 13


After that the Wiimote did not move the mouse cursor anymore. Then I tried running MAME with these settings. I used -verbose mode to get debug info and piped it to less to be able to inspect the log. Now the Wiimote was dispalyed in the "Initializing Joysticks" portion.
$ SDL_JOYSTICK_DEVICE=/dev/input/event14 mame -verbose -sr 11025 timecrs2v2b | less

From the MAME menu (with TAB key) I could go to input and lightgun settings and set the lightgun 1 analog X and Y properly by moving the wiimote. The setting indicated something like JS1 axis 0 and JS 1 axis 1 if I remember correctly. The Wiimote worked properly as a lightgun!

I assume the problems come to the fact that the Wiimote operates as mouse and joystick simultaneously, why SDL does not really know which it is. That's why the device name has to be told explicitly. I also wonder if pointing it to /dev/input/js0 also, but I didn't test that yet.

For reference, here is the relevant parts from my ~/.mame/mame.ini to set the joystick to emulate lightgun:
# CORE INPUT OPTIONS
coin_lockout              1
ctrlr
mouse                     1
joystick                  1
lightgun                  1
multikeyboard             0
multimouse                0
steadykey                 0
offscreen_reload          1
joystick_map              auto
joystick_deadzone         0
joystick_saturation       0.85
natural                   0
joystick_contradictory    0
coin_impulse              0

# CORE INPUT AUTOMATIC ENABLE OPTIONS
paddle_device             joystick
adstick_device            keyboard
pedal_device              keyboard
dial_device               keyboard
trackball_device          keyboard
lightgun_device           joystick
positional_device         keyboard
mouse_device              mouse


And after storing the settings in MAME ingame menu, the following config in ~/.mame/cfg/timecris.cfg:
  <input>
    <port tag=":LIGHTX" type="P1_LIGHTGUN_X" mask="4095" defvalue="381">
      <newseq type="standard">
        JOYCODE_1_XAXIS
      </newseq>
    </port>
    <port tag=":LIGHTY" type="P1_LIGHTGUN_Y" mask="4095" defvalue="163">
      <newseq type="standard">
        JOYCODE_1_YAXIS
      </newseq>
    </port>
    <port tag=":MCUP5A" type="P1_BUTTON1" mask="16" defvalue="16">
      <newseq type="standard">
        JOYCODE_1_BUTTON2
      </newseq>
    </port>
    <port tag=":MCUP5A" type="P1_BUTTON2" mask="32" defvalue="32">
      <newseq type="standard">
        JOYCODE_1_BUTTON1
       </newseq>
    </port>
  </input>


Hopefully this will help someone to get the Wiimote to work in MAME. I also got the wiimote to work as a NES zapper in Mednafen, but I will write about it later.

perjantai 14. kesäkuuta 2013

Using Wiimote as mouse

I have wanted to use my Wiimotes with my HTPC since they would be great for things like point-and-shoot games etc. Maybe for media center too, but I haven't tried that yet.

Anyways, there are multiple tutorials on the net for getting wiimote to work, like CWiiD tutorial on Ubuntu wiki or XWiimote tutorial on Arch wiki.

Basically, this is how I understood, CWiiD is the older driver which is no longer developed and XWiimote is the newer one which behaves better.

XWiimote has driver for xorg and you pair the Wiimote just like any other bluetooth device. So it should be the method of choice. However, it does not yet support the IR pointer which I want to use. So until that it's a no-go.

CWiiD requires an user-space application which handles the Wiimote communication, and an evdev driver (some generic driver I think) communicates with xorg. CWiiD has IR-pointer support, and after few days of messing around, I got it to work.

First, I installed the necessary packages: bluetooth which installed bluez and wminput. Those installed all other libraries etc that were needed.

Then running wminput -c ir_ptr -w and pressing 1+2 on the Wiimote connected the mote and everything worked, except for the IR pointer. After reading xorg.log and browsing around the net I found the solution.

Problem is that the driver reports both relative and absolute movement, and ir pointer uses absolute which was discarded for some reason. Also, as the driver is loaded runtime using udev and everything, normal configs added to xorg.conf do not work. I worked around this by creating a new input class config for evdev; /usr/share/X11/xorg.conf.d/61-evdev-wiimote.conf which contains following:


Section "InputClass"
 Identifier "Nintendo Wiimote"
 MatchProduct "Nintendo Wiimote"
 MatchDevicePath "/dev/input/event*"
 Driver  "evdev"
 Option  "IgnoreAbsoluteAxes" "false"
 Option  "IgnoreRelativeAxes" "true"
EndSection

This forces xorg to use the reported absolute pointer location (IR pointer) instead of relative location (acceleration sensors etc), so now the pointer works. Only missing is a proper IR source, but a flashlight works fine until then.

Also one should note that the ir_ptr config is located in /etc/cwiid/wminput/ and from there the button and axis mappings can be changed.

Hopefully this helps others too, it took quite a while to figure that input class thing out.

perjantai 30. marraskuuta 2012

Amiga emulation with Amiga forever and WHDload

This I'll tell how I configured Amiga emulation on my HTPC. Now, Amiga games typically are on several disks, and even though MythGame supports those, it does not work very well with Amiga emulators, e-uae in my case. Mostly the problem is that one must change the disks and stuff like that, which is quite clumsy in my opinion. I know there is fs-uae which probably would work better in that aspect, but it was horribly slow on my setup.

Anyways, I bought Amiga Forever from Cloanto. For just a few dollars, I got all necessary Kickstart ROMs, bunch of games, and Workbench (the nice OS).

Amiga Forever has a very nice Windows interface with one click launching of games etc, but it does not work so well with Linux. So I downloaded WHDload, which is an Amiga program intended to allow hard disk installing of Amiga disk games.

So, to set up my emulation, I created two directories: ~/Amiga/HDWorkbench and ~/Amiga/HDGames. In e-uae config, I added those to my uae config, and installed Workbench on the HDWorkbench drive, following this nice guide. After that, I installed WHDload (copied it to the hard drive and installed using Workbench).
Now everything is ready for games. Just copy the WHD installs of them to HDGames dir and launch them from Workbench! But what about MythTV?

I created a small script to write a proper startup file for amiga, so that when it boots, it automatically launches the game. The script looks like this, I call it run-uae:

#!/bin/sh -e
# Script to automatically lauynch e-uae using WHD game selected
# Also changes qjoypad layout to UAE
#
# Works by creating a User-Startup file which launches the
# game when UAE boots, and then deletes it when done.
# Note that paths MUST be correct and UAE must boot to
# Workbench with the selected configuration.

if [ ! $# = 2 ] || [ "$1" = "-h" ]; then
  echo "Usage: run-uae <config> <game>"
  exit 1
fi


AMIGA_GAME_PATH="Games:"
AMIGA_STARTUP_FILE="~/Amiga/HDWorkbench/S/User-Startup"

CONFIG="$1"
AMIGA_SLAVE=$(basename "$2")
AMIGA_PATH=${AMIGA_SLAVE%.*}

echo "${CONFIG} ${AMIGA_SLAVE} ${AMIGA_PATH}"
echo ${AMIGA_STARTUP_FILE}

# Create user-startup
echo "cd \"${AMIGA_GAME_PATH}\"" > ${AMIGA_STARTUP_FILE}
echo "cd \"${AMIGA_PATH}\"" >> ${AMIGA_STARTUP_FILE}
echo "whdload ${AMIGA_SLAVE} Preload PAL" >> ${AMIGA_STARTUP_FILE}
echo "uae-configuration SPC_QUIT 1" >> ${AMIGA_STARTUP_FILE}

# Change qjoypad layout to UAE
qjoypad --update UAE

# Run e-uae
e-uae -f ${CONFIG} -G 1

# Reset qjoypad configuration
qjoypad --update "MythTV"

# Remove startup file for next clean boot
rm ${AMIGA_STARTUP_FILE}

You need to tune the parameters in the beginning, the game path to have the Amiga drive label, and the other is real path to the user-startup file. And you point to the .slave file of the game. I think it might be better to use the .info file, But I haven't had the time to do and test the change. This works for 99% of the games out of the box.

In Mythgame the setup is like this:
- Player name: Amiga
- Type: Amiga
- Command: run-uae ~/.e-uaerc %s
- ROM path: ~/Amiga/HDGames
- Working dir:
- File extensions: Slave, slave
- Uncheck the box for multiple disks

Running Windows games in MythTV

Second post coming, after a while! Nice.

This time it's about how to properly play Windows games under MythTV and wine. Or MythGame to be precise, but it's part of the system, so...

On the MythGame wiki page there was nothing about wine, but after reading the other topics and experimenting a bit, I ended up with following system:


  • I created a ~/Windows/ directory, and configured wine to use it as a D: drive. I will install all my Windows games there.
  • All launchers will be stored in a new directory, ~/Windows/conf
  • MythGame launcher for wine looks like this:
    - Player Name: Windows
    - Type: Other
    - Command: sh %s
    - ROM path: ~/Windows/conf
    - Working dir:
    - Extensions: sh
    - Uncheck the box about multiple ROMs
    
    
In the start, all launchers were just simple cd <gamedir>; wine <game.exe>, but I ended up with something better:

Often my windows games crashed, leaving the MythTV front-end broken, or had some problems with colors or resolutions. I crawled the web about launching another X session for wine games, because apparently there would be benefits:

  • If a game crashes, it doesn't screw up the front-end
  • Colors and resolution can be set independently of the front-end
  • No other programs (opengl?) running on the same X server -> better performance
  • The "Virtual desktop" in winecfg can be used (if game won't work without it) and it can be fullscreen, or if not, there is nothing on the backround anyways!
Of course it's not that easy. For some reason, launching X with only wine as a client didn't work, the new server just didn't work. But after few days of trying, I got it to work using a shell as the client.
At the same time, I figured I could use fuseiso to mount cd images automatically to ~/Windows/cdrom, which was configured as a cdrom drive in wine. This way: no hand mounting or inserting cds!
So here's an example of a working sh file to be put into ~/Windows/conf. It mounts the cd, set's resolution and launches the game. When the game ends, it
returns automatically to front-end! Neat!


#!/bin/sh

# Use FUSE to mount the cd image
fuseiso ~/Windows/Game_CD.iso ~/Windows/cdrom

# Launch new X server, with retro style (striped background, optional)
# and closing after the game is finished
# If not using NVidia gfx card, remove the & nvidia-settings ...
# And if you need to change color depth, use something like this:
# X :3 -retro -ac -terminate -depth 16
X :3 -retro -ac -terminate & nvidia-settings --load-config-only

# Forces the system to have a break for 2 seconds, X doesn't launch instantly
sleep 2

# Set correct resolution for this game, then
# launch the game on the new X display
cd ~/Windows/Game_dir/
DISPLAY=:3 WINEDEBUG=-all xterm -e "xrandr -s 800x600 && wine Game.exe"

# Unmount cdrom when done
fusermount -u ~/Windows/cdrom

Hopefully this helps others too, I think this is the only way to properly run Windows games (and why not other games too?) under Linux!

torstai 20. syyskuuta 2012

NES Emulation on MythTV

Thought that I might as well write about Nintendo emulation right away.

Game emulation in MythTV requires a MythGame plugin, which might be installed automatically, or it can be installed through the control center. It adds a new Games section in the MythTV main menu and in Settings.

I've tried several NES emulators, but I've liked fceux and Mednafen the most.

Fceux

Fceux wors fine, but I didn't find a way to quit it using only the gamepad. So I configured qjoypad so that one button in my gamepad is same as pressing esc key on keyboard. That helps a lot.
For mythgame to launch first the qjoypad and then emulator, I wrote a little script:


#!/bin/sh -e
# Script to launch FCEUX with correct settings
# First, sets qjoypad bindings, i.e. bottom triggers
# quit the emulator (or what ever is defined)
# then runs fceux, and finally changes qjoypad layout back

# Update qjoypad joystick lists and select FCEUX
qjoypad --update FCEUX

# Run fceux
fceux -fullscreen 1 "$1"

# Back to default mapping mode
qjoypad --update "MythTV"

I named it run-fceux, and in mythgame config, I call "run-fceux %s" and it works fine. Fceux has crashed on me some times, and it seems to have some minor issues every now and then. Otherwise it's fine.

Mednafen

Just today I tried Mednafen and already like it better than fceux. Only problem was getting the gamepads to work, but in the end it was easy:

- Start mednafen from command line, e.g. "mednafen /path/to/rom.nes"
- Press alt+shift+1 and you're asked to press every gamepad 1 button in order, up, down, left etc. You can bind many keys to do the same thing, when you're ready, press the same key twice.
- Press alt+shift+2 and do the same thing for second gamepad.
- If you want quit button in your gamepad(s), press F2, then ESC. Now you can press all different quit keys you want. Finish with double ESCs so keyboard will function as before.
- Done. Easy, huh?

I wrote similar script as before to get rid of my gamepad bindings for MythTV, and the command line to launch mednafen is following:
mednafen -nes.stretch 1 -fs 1 -vdriver 0 "$1"

Currently I suggest using Mednafen for NES emulation, it seems to be very clean and nice.