Thursday, September 3, 2015

Java: "unmappable character for encoding ASCII"

I hit a strange compile error today: a project that compiled in several environments was failing to build in a build server. The error was in the "copyright" symbol in all .java files, something like...

...../.../MyFile.java:8: error: unmappable character for encoding ASCII
 *  ?? Copyright XX All Rights Reserved

     ^

Note that "file MyFile.java" showed UTF8, and this was indeed its encoding. Turns out Java was deciding or guessing it was ASCII, incorrectly.

One solution was to force the encoding, like this:
export JAVA_TOOL_OPTIONS=-Dfile.encoding=UTF8  
And even better, since I use Gradle, was to use compileJava.options.encoding. In my top-level gradle file:
subprojects {
    apply plugin: 'java'    compileJava.options.encoding = 'UTF-8'
... 

I hope this helps someone else!

Monday, December 15, 2014

Happy Birthday, dad

This is how it all started for me... The notes below are from a old notebook, 22 years ago. It was 1992 and I was coding my first programs: my father and I were learning to code together. He, as always, was able to spot and encourage my passions. Programming became my passion, profession and way of living.

I do not have digital records of that age, and had no printer either, so these handwritten listings are all that was left from that BASIC code. I can see my coding style changed, too...


He would turn 75 years old today. Just he left exactly weeks ago -- now we know he is free from his damn awful disease.



I miss you, Papá.

Wednesday, June 11, 2014

XBMC in Odroid U3 (cont'd)

I think I owe an update on the Odroid U3 topic I started months ago.

First, I should say I quickly abandoned the Android image: for the reasons described in the previous post. I moved to some "Game Station Turbo" image, linux-based, that I have used for months. Performance was decent, but it was limited to 720p and even playing videos in this resolution was not totally smooth. Some videos would hang, also (video freezing, but audio continuing -- workaround was to press Stop, then play again the video resuming from the position I just stopped it). I never used the gaming features of that image, by the way -- they did not work for me (I only tried some ROMs but was not that much interested in doing further research). Asking in the forums, they said the 720p limitation was a problem in the drivers, that should "get solved in a few months". So I waited.

More recently I went to the forums again looking for updates. I tried a couple of different images, until I found this one, based on Ubuntu 13.10 and LXDE. Driver problems are fixed, or replaced by some other drivers... and the image boots from install in 1080, and plays 720p videos absolutely smoothly! And 1080p seemed smooth at the first try, though I need to play an entire movie to be sure.

(For some technical note: Installing is similar as other images: "xz -cd ((image name.xz)) | pv > /dev/mmcblk0", and then extend the last partition to the end of the SD card space).

Seems they are still doing updates on the drivers, so instructions to re-download, compile and install them are in that forum thread. The image still uses XBMC 12.3, but a v13 will come soon (when there is a final release; now xbmc 13 is still beta). I can't wait! EDIT: mdrjr confirms one should not need to update drivers -- they are part of the image already.

I am very thankful to memeka, mdrjr and the other folks from Odroid community who are working on this. This is a major update for those using Odroid as XBMC media center, as I do, and now it makes the Odroid absolutely worth every cent!


Thursday, February 20, 2014

Unlocked my Motorola Defy

Locked phone!
I have a 3yr-old Motorola Defy, and recently upgraded to another model. This Defy came from Personal (carrier in Argentina), and I wanted to use it with a SIM from a different carrier (Claro). When I put that SIM card... a message would ask for "Pin de desbloqueo de red de la tarjeta SIM".

The phone was usable (apps, wifi), but no mobile signal was picked.


Tried PUK code, known short PINs, asked the subsidy password to my carrier, and nothing worked.

(Interestingly enough: Unlike other people's experiences, I phoned Personal and after verifying I am the owner of the phone, they just gave me the subsidy password in a couple of minutes. Unfortunately, it did not work with my phone).

I suspect the code did not work out of the box because my phone was re-flashed long ago, I had installed Cyanogenmod 9 to get Android 4.x.

System Settings / version
I tried some "baseband selector" but this did not help. I think this option is the same thing available in Cyanogenmod options menu -- you just select the frequencies, but the phone is still locked.

So after looking for hours (days), I found one solution based on installing some update from the recovery menu. I had not used this for a long time so it was all fun and scary... again.

The source is this 51-pages forum in XDA. The solution uses a file named ICS_Defy_softunlock_v1.3(EPU_U_00.59.01).zip, and it is called a "soft unlock". I am documented what worked for me:

Pre-requisites:
  • To flash CM9, I had already rooted and installed 2nd-init. I did this long ago, and it is the only actual requisite.
  • I had CM9 previously installed - so the "ICS" version of the patch worked for me (and not GB for Gingerbread). I believe both CM7 and CM9 work.
  • As shown in my System Settings page, my base band version is EPU93_U_00.59.01, exactly what this soft unlock requires. If yours is different, you may need to install the baseband update as well (from the same XDA forum).
Steps:
  1. Reboot in Recovery mode
    Shutdown menu / recobe
  2. Select "Install zip from SD card" and "Choose zip from sdcard"

  3. Pick the ICS_Defy_softunlock_v1.3(EPU_U_00.59.01).zip file and confirm.
  4. Reboot your phone without SIM card (or with the original one -- not the target carrier SIM!)
  5. Once fully rebooted, power off, insert new SIM card, and start the phone again.

    It worked for me! The screenshot shows the phone in Claro network now.
Working with new SIM
I read that this, being a "software unlock", is not persistent across ROM changes. So if I ever replaced the current CM9 in this phone, I might need to do this patching again.... Hopefully this blog post will help me at that time!

Thanks xdadevelopers!

Friday, February 14, 2014

ODroid U3: Hello Android

I got an Odroid U3 , a tiny, low consumption and yet powerful computer. I want to replace my dead Raspberry Pi which acted as mediacenter, and add some gaming to it.

It turns out that knowing what to install is not totally trivial. There is a myriad of images, different linux and android versions. I am documenting what I started doing:

  • There is a big collection of image links here.
  • I downloaded an android Ice Cream Sandwich, 4.0.3. (The 4.1 and 4.2 versions were said to not work from SD cards; which is what I bought (eMMC is more expensive)).
  • The actual installation steps are here. Some clarifications below...
  • First, one needs to burn a .xz image:
    xz -cd ./IceCreamSandwich-4.0.3_CouchPotato-U2-HDMI-SD.20140101.img.xz > /dev/mmcblk0
  • This image is from a small SD, and I needed to resize to my 16Gb card. The partition to enlarge is some FAT32 in the middle, so there are quite a few steps involving backing up contents and copy them back. Details here.
    • What takes time is (1) to burn the .xz, initially. The backup is just about 250Mb in size

My first impressions:
  • Android runs smooth, some games are nice too. But I already found some cons...
  • I cannot have my USB external HDD get recognized. This one has two ext4 partitions (full of movies I was using with my old Raspbmc). Some "StickMount" and "Paragon NTFS" are installed, and I tried others, but no luck yet.
  • XBMC was slow to play a 720mb from a pen drive (fat32, it did work). Another player pre-installed in this image worked ok, with hardware decoding.
  • Three times already, Google Play was stuck and unable to download new stuff from the android market (some error shown in the notifications). The only solution I found from the forums is to wipe Play's data from android Settings; then remove my gmail account, reboot, and start over adding my account and re-downloading stuff.
  • The whole UX is far from ideal. The OS thinks it is a tablet. All UI is oriented to dragging, pinching, using huge amount of scrolls -- as if your fingers were on a touch screen, and not moving a cursor on a big TV. Totally awkward on a small touchpad from my wireless keyboard. Games expect you to touch everywhere too... not to press keys. I guess this is android!
I just read there is a GameStation Turbo including XBMC with CEC support (for my TV remote) and some games too.... It seems to be linux, too, which I will like more. Going to try out the next few days!

Monday, February 10, 2014

Cut my SIM to MicroSIM size

I bought a new phone, with the surprise that my SIM ("Mini-SIM", formally) would not fit: This and other new phones use Micro-SIM (or even Nano-SIM) format. The chip contacts are the same, just with less plastic around.

You mobile carrier company should be able to swap your SIM card or just cut it with one of the many automatic clippers around. Some of them charge for this -- I am sure they would, in my country. And, there is the hackish way which I am of course always up to: cut it yourself!

There are many posts about this on the web. I just picked one of the mostly linked templates, and cut it. Here is the before:

And the after:
(I sorry - this is not the card after cutting - just the leftovers: the card is in my phone now!)

If you are careful, I think it should just work. It was not such a complicated or exact work to me.

My only advice, maybe a refinement on what I read, is that you mark the cuts with a cutter (and a metal ruler) before really cutting, which I did with regular scissors. The lines you "draw" with the cutter are perfectly thin, better than using a marker or pen.

This was no software hacking. Tangible stuff this time!

Thursday, December 5, 2013

Runkeeper and my Garmin GPS

The problem

I am an avid runkeeper.com user. I log every hike, every bike ride, everything. I have used two devices: my android phone, and a Garmin Vista hcx GPS. The later is particularly useful for my long hikes: It is sturdy, waterproof and batteries last very long.

My problem with my Garmin GPS is that something in the way it logs my tracks makes Runkeeper assume I am doing constant pauses, and resuming a few meters later. This takes all calculations (distance, total climb) very far off what I get from what I get from Mapsource or Google Earth. And this cannot happen in Runkeeper where I expect to have every possible statistic of my activities!

This has been happening on my activities for the last 2 or 3 years of Runkeeper usage...

Why now?

Long ago (Aug 2011) I reported this issue to the support team. This was their reply:
From: Jake
Subject: Problem in climb calculation

Hernan, no known issues with Climb calculation, it appears you have a large number of pause/resume points in this activity, which may be what accounts for the discrepancy.  It looks like there were gaps between pause points that may have accounted for large elevation change.  If you track an activity continuously, do you notice the same discrepancy?

Here'e how we calculate climb....http://support.runkeeper.com/kb/troubleshooting/how-does-runkeeper-calculate-elevation-and-climb

View this Discussion online: http://support.runkeeper.com/discussions/problems/10363-problem-in-climb-calculation

Unfortunately the link is now broken -- they have moved their forums, and apparently, garbage-collected old tickets. A total shame :(

This is why I have been using my phone more and more, and my GPS unit less. But after a 3-day hike where I really had to use the GPS, I decided to fix the issue...

The hack

The idea is really simple: Just make the tracks I upload "smoother", by adding points whenever two points differ in time (or distance, or elevation?) beyond what Runkeeper would consider a 'break'.

Normally, I load all my tracks to a .gdb file (from MapSource), and run scripts to export each track to all .gpx, .tcx and .kml -- just in case! Then I upload the .gpx or .tcx to Runkeeper. So I decided to do some post-processing of these files.

I found gpxpy, a Python library to read and write GPX format. One of the examples in the github page already parses out a file, and even prints some statistics -- almost exactly what I need. So what was left to me to do was to complete this, and I came up with the python script I am attaching at the end.

Results

I have uploaded and re-uploaded my 3-day hike, and now the numbers look much more accurate. There are still some pauses, but they may be totally true -- these are 10-hour hikes, and they do have pauses -- just not every minute.

Here is an image of my activity before fixing the track:
and this is the same activity, after the fix:
note the improvements: 1608m climbed (against 439), 12.95km instead of 11.07km, and a much cleaner curve!

I would love to receive feedback from other users -- as well as Runkeeper staff! For me, it is not a big deal if my GPS is too old or incapable or producing the correct input formats for them. I will keep loving and using Runkeeper!

If you found this article useful, or need help trying to use the code yourself, please leave a comment!

PS: The source code