Musing Journal #5

Electric Bike Cost

If you have been following my posts, you know that I have been smitten by electric bikes. No wonder. They are clean, light, simple, and really a good transportation mode all around. The fact that I have bike path from the house really does seal the deal. There is only one problem: The cost.

Now, I can go buy myself a cute little red scooter for about $2000. A used one can be had for $1000. So, I really don't want to spend more money than $1000 for an electric bike. A scooter can get you places bikes can, faster and safer. Of course, there is the cost of ownership. Scooters costs more to insure and maintain. But let's face it, with 100 mpg effective expense, it just doesn't cost all that much.

But how about electric bikes? You can always pedal. Yes, that's true. But with regular bike, that's free. How about the cost of an electric bike? There have been a lot of calculations thrown about that says an electric bike gets an equivalent of 1000 mpg! Some people, in fact, attached the battery charging unit to solar cells. That's probably about 1 million mpg. How can a scooter beat that?

I'm not interested in calculating pedal power into the equation. So, first, I'm taking the range of motor only. Then I take the cost of purchasing replacement battery. Finally, I take the amount of recharging the batteries can take before losing capacity. So, the true mpg cost of an electric bike is Price of batteries / (mile per charge * number of charge). That gives you dollar per mile. A simple price check will give you dollars per gallon. That will give you mile per gallon figure.

In my calculation, I get about 80 mpg for electric bikes. So, that's slightly less than that of a scooter. I consider, cost wise, scooters and electric bikes are the same. Perhaps I will change my mind later, once the battery technology has improved much and gasoline cost more that it is now. However, that's some time in the future and for now, I will not buy an electric bike that costs more than $1000. I'd rather have a scooter!

Book Review #5

Zen and the Art of Well Being
Eric Chaline

This is an old book, published in 2001. I find it interesting that current self-help book deals with medicine. As in, take this medicine for brain, this medicine for stomach, this miracle diet for being thin, and so on. Rarely, that there is a book that emphasize balance. This book, with its Taichi principles does have it. It also has well-being as the core concept. It's certainly a very unique self-help book. It's closer to philosophical look at being healthy, than it is a definite step-by-step method to being well.

And that's why I like it. There is a sense of effortlessness throughout the book, that I enjoy reading. It's the most enjoyable self-help book I've read so far. Not much for resources, though. That I will have to research on my own. Yet, I do not regret purchasing this book. It's worth a read from time to time, as I strive to achieve a balance between work and play. Yin and Yang. Zen.

Raspberry Pi Journal #5

SD Back Up Frustrations

So, I was going to back up my SD card. I think that there is a good chance that my SD card will go bust someday. I'd like to be protected. Considering that I install a lot of program, and it's not over yet, there is an excellent chance that the SD card will go out eventually. Especially since omxplayer is still messing up my system. The last time I used it, the screen actually got shifted in the middle. That is, all four corners of the desktop are centered on the screen. Sigh.

So, having the need to back up my SD card, how do I do it? A lot of instructions on the Internet says to use Win32 Disk Imager. I suppose it works fine, but come on, Debian is a very powerful OS. Are you saying I have to use Windows just to back up a Linux OS? That's silly.

So, I dig deeper. It turns out that I have to dig quite deep to uncover DD. DiskDump (or Disk Destroyer) seems to work fine. This is how you use it:

dd if=/dev/sdb of=/path/to/backupfile.img
if=input file or sd card
of=output file

And this is where I stop. The method obviously works if you're copying an SD card to another place, such as a flash drive. But, how will this back up my current system? I have to take it out of the machine and back it up manually? That's not how back up supposed to work, does it?

I understand that the output is not compressed, but I don't see it as a drawback. You can simply output to sdout and pipe it to gzip. There you go, compressed on the fly!

I also understand that if I specify the wrong SD card, I can mess things up. I read very carefully the text I have, but there is no specific mention how the SD card will be destroyed. I'm assuming that the destruction will happen on the output side, not the input side. But if so, isn't that natural?

All I can tell you is that the process will not backup the current running OS. Also, there is no instruction on how to restore the data. The only hint is that if "of" is given drive, it will try to "rewrite the whole disk". I'm wondering if that means the whole partition is intact. If indeed we're copying two SD cards, mirroring one another, I think that's a desirable outcome since that way, we get to skip a step. If one card is busted, well, no need to reflash the SD. Just use the back up SD right away!

Researching this method of back up is very frustrating and time consuming. Mirroring SD card is not what I'm looking for! I want to back up the OS, and I want to know how to do it, live.

I'm thinking to partition /boot and /home separately. I think I can just tar /home like this:

tar -cvzf tarball.tar /home/ 

and that's that. Extract the files by

tar -xvzf tarball.tar /home/

That should do nicely. I also wonder if the command

tar -xvf tarball.tar

all by itself is enough. I checked it. Sure enough, it works! Apparently, there is a check in there if the archive is compressed, it will automatically decompress. I checked out the output and there seems to be 4 bytes difference. I wonder why that is. There's no other differences that I can see.


There are two commands that you can use: "tar --help" and "tar --usage". Both screens are simultaneously overkill and not enough sample usage for everyday use. Hmmmph.

In any case, I still don't know how to back up my system, without shutting it down and take it out to another computer. Very frustrating!

Do you people are actually satisfied with the back up instruction that requires you to shutdown your Raspberry Pi, remove the SD card to Windows machine, and run a disk imager? I know that Linux has a live-back up system. How about doing instruction for that? I have an SD card in Raspi, and another one via USB. I want to backup the system to that USB+SD card. It's okay if I have to get a bigger card, but please don't tell me I need to shut the system down! That's just so inconvenient, and isn't the idea of getting a computer is convenience?

There are many, many web pages that tells you to use Windows to back up your SD card. Hello? Do you not see why that is not desirable? Worse, the instructions just mirror one another. I get repetitive instructions that is useless, and really, just a bunch of noise. I ran out of time trying to dig out the proper instruction. And before you ask, yes, I searched for "live backup". The few forum pages that I've seen, skirted the issue and did not answer at all.

I'm pretty sure there is a proper instruction in there somewhere, because I'm having trouble believing that people are willing to put up with shutting down the device every time you want to make a back up. It's just that the bad instructions are everywhere, and not enough people putting out good instruction to counter it. I have yet to check this, but I'm getting very frustrated. I wonder if the "back up your Pi with Windows" instructions are even in TheMagPi magazine? Because, IMHO, that's the boneheaded way to do it. Learning computers are fragile, and what good would it do to send cheap computers if you need an expensive one just to back up your data?

Of course, next thing I know, lots of people will be criticizing me for unwilling to pull the SD card out of the Raspi to make a daily back up. Uh-huh. And they wonder why people don't back up their SD cards.


BTW, I finally did an "rsync -r --progress * /media/5185-5397" where the number is the SD card on my USB. Works fine ... for a directory.

Petit Computer Journal #5

Petit Computer Journal #5 - Buttons and Touchscreen

Let's take a little detour for now. We should be doing strings and graphics, but I want to do something else real quick: Buttons, Touchscreen, and Keyboard. In other words: INPUT.

We have done buttons, touchscreen, and keyboard inputs before. However, I'm interested in doing them all at once. And the trick is to do it without stopping the other input methods. That's not too easy.

Regarding keyboard input method that doesn't stop other process, we have INKEY$. We also have touchscreen variables TCHX,TCHY and all those. How about buttons? We have BUTTON(0), and that is sufficient. So, at the surface, we have all that we need.

The thing is, I don't want to have to structure the program into multi-threading format at this point in time. So, we will have to make some sacrifices. The INKEY$ is well enough. How about buttons and touchscreen?

In Touchscreen, it is convenient to have a drag-and-drop process. That means X1,Y1,X2,Y2,TouchStatus. Let's build that capability.

@SETT
IF TCHST==0 THEN TS1=TCHST:RETURN
IF TS1==0 THEN TX1=TCHX:TY1=TCHY:TS1=1
IF TS1==1 THEN TX2=TCHX:TY2=TCHY
TS1=TCHST
RETURN

That looks simple enough. Basically, we want to update the variables if TCHST==1. The first line takes care of that by returning from subroutine if TCHST==0. Next, we want to see which pair we want to update X1,Y1 or X2,Y2? And that's all there is to it!


The buttons isn't so simple, though. There are 4 possible arrangements that I can see:
1. No Wait+Multiple: BUTTON(0)
2. No wait+Single: @SETB1
3. Wait+Multiple: @SETB2
4. Wait+Single: @SETB3

Of these, we want no wait version. If the no wait version is equivalent to INKEY$, then the wait version is equivalent to INPUT. The whole process involve trying out different versions of the commands. You see the finished product as clean, but I assure you that the process involves repeatedly trying and failing to come up with that clean method. You do not see the hard work that is done. At least, if you ever wonder why my progress is at glacial pace, you know the reason: Lacking tutorial such as this, I do a lot of experiments, not all of them successful.

There are 4 cases and only 3 subroutines. The first case can be easily met via BUTTON(0). The rest is done with simple subroutines. It only works on the first 8 bits, corresponding to UDLRABXY. This is because the method I use requires string characters, and those only goes to 255. I typed in the character in the actual program, but for the purpose of tutorial there are two index variables used by INSTR()

1. IST1$=CHR$(128)+CHR$(64)+CHR$(32)+CHR$(16)+CHR$(8)+CHR$(4)+CHR$(2)+CHR$(1)
2. IST2$=CHR$(129)+CHR$(65)+CHR$(33)+CHR$(17)+CHR$(9)+CHR$(5)+CHR$(3)+CHR$(2)

I use this technique a lot as it simplifies things greatly. It's not the fastest running code, and so only amateur hobbyist would use it. Certainly not a professional quality code. If need be, I may changed the code later to a more efficient one. But I like doing rapid prototyping in the beginning.

One more thing, the no wait version is tricky. If you check out the clock, you will see that no-wait @SETB1 does cause the program to stop when you press the button for a long time. A way to fix this would be to use a variable, but I would rather just do it directly with BUTTON(0) or @SETB2.

@SETB1 :'SINGLE FIRE
INBUTTON$="":Z=BUTTON(0):IF!Z THEN RETURN
FOR Z=0 TO 1:Z=BUTTON(3):NEXT:Z=Z AND 255
Z=INSTR(IST2$,CHR$(Z)):IF Z< 0 THEN RETURN
INBUTTON$=MID$("YXBARLDU",Z,1)
RETURN

@SETB2 :'CONTINUOUS
INBUTTON$="":Z=BUTTON(0):IF!Z THEN RETURN
Z=Z AND 255:Z=INSTR(IST1$,CHR$(Z)):IF Z< 0 THEN RETURN
INBUTTON$=MID$("YXBARLDU",Z,1)
RETURN

@SETB3 :'WAIT
INBUTTON$=""
FOR Z=0 TO 1:VSYNC 1:Z=BUTTON(1):NEXT:Z=Z AND 255
Z=INSTR(IST2$,CHR$(Z)):IF Z< 0 THEN RETURN
INBUTTON$=MID$("YXBARLDU",Z,1)
RETURN

And those are the functions. Next, let's write a quick demo program to demonstrate the different functions. It may be best that you write a program and save it because you will be using this at all times. I know I do!

'BUTTON/TOUCHSCREEN TEST EXAMPLE
CLS:CLEAR:P1=0:P2=1
@MAINLOOP
LOCATE 0,0:?TIME$
VSYNC 1:A$=INKEY$():?A$
GOSUB @SETB1:'?INBUTTON$;
GOSUB @SETT

IF INBUTTON$!="" OR TS1 THEN GOSUB @DT
GOTO @MAINLOOP

@DT :'DRAW TEXT
IF INBUTTON$!="" THEN L1=(L1+1)%32:LOCATE L1,1:?INBUTTON$;

'DRAW BOX
IF INBUTTON$=="L" THEN P1=P1+15
IF INBUTTON$=="R" THEN P1=P1+1
IF INBUTTON$=="U" THEN P2=P2+15
IF INBUTTON$=="D" THEN P2=P2+1
P1=P1%16:P2=P2%16
SX1=FLOOR(TX1/8):SY1=FLOOR(TY1/8)
SX2=FLOOR(TX2/8):SY2=FLOOR(TY2/8)
FOR X=SX1 TO SX2:FOR Y=SY1 TO SY2:
C$=CHR$(151):COLOR P2:'0=BIG BLOCK CHARACTER IN PETIT COMPUTER
IF X==SX1 OR X==SX2 THEN C$=CHR$(150):COLOR P1:'1=VERT LINE
IF Y==SY1 OR Y==SY2 THEN C$=CHR$(149):COLOR P1:'2=HORZ LINE
IF X==SX1 AND Y==SY1 THEN C$=CHR$(152):COLOR P1:'3=UPPERLEFT
IF X==SX2 AND Y==SY1 THEN C$=CHR$(153):COLOR P1:'4=UPPERRIGHT
IF X==SX1 AND Y==SY2 THEN C$=CHR$(154):COLOR P1:'5=LOWERLEFT
IF X==SX2 AND Y==SY2 THEN C$=CHR$(155):COLOR P1:'6=UPPERRIGHT
LOCATE X,Y:?C$;
NEXT:NEXT

RETURN

For some reason, my computer does not read my memory card. That's a setback. I have to have those special characters, and so, I'm forced to do it the hard way, which is very annoying. However, either I overcome that setback, or I don't do this at all. I can work on the DSi no problem, but if I want to share it, I have to do this thankless work of translating those characters into their numeric equivalent. I wrote a simple program just for that:

'ASCII TABLE
S=0
@MAINLOOP
CLS
FOR I=S TO S+15
R=I%16
LOCATE 0,R:?I;:LOCATE 5,R:?CHR$(I)
NEXT

GOSUB @SETB3

IF INBUTTON$=="U" THEN S=S+16
IF INBUTTON$=="D" THEN S=S+256-16
S=S%256
?:?"S=";S;"   ";INBUTTON$:WAIT 60:'OPTIONAL FOR DEBUGGING
GOTO @MAINLOOP

And that's it. Not even 10 minutes. You need to provide Subroutine @SETB3, but that's trivial. Just copy the one above.

Problems and How to Ask Questions

You know how people say there's no such thing as stupid questions? I know I'm bucking the convention here, but I'd say there are! Here's a sample, quoted in its entirety:

"Help! SAVE doesn't work."

I'm not saying that SAVE command is so easy that it cannot fail. I am saying that the question doesn't even begin to show the framework in which the problem occurs. We need more data! You know how PRINT statement works, right? What if there's somebody who ask help like this: "How do you use PRINT?", following your answer with "It doesn't work."

You know it works, and you know how it works. The problem is, how does it doesn't work? You have no clue as to what problem this person encounter. So, here is how you handle a problem that you cannot solve, because the unwritten rule is, if you ask a question that you later answer without any prompting whatsoever, YOU JUST ASKED A STUPID QUESTION THAT YOU KNOW THE ANSWER TO!

Problem solving technique:
1. Ran into problem, WRITE IT DOWN!
2. Write down all the relevant elements.
3. Read the Manual/Help file
4. WRITE ALL THE POTENTIAL SOLUTIONS DOWN.
5. Implement them all.

That's step-by-step. You are not allowed to skip steps. Half of your problems can be solved this way. As for the rest, well, that's when it gets tricky.

Hard Problem Solving:
1. You are tired. STOP AND GO TO SLEEP!
2. Wake up. Eat something solid
3. Repeat problem solving steps above.

By this time, if you followed this advice, a lot of you would do a lot of face palming "Of course! Why didn't I think of that?" sequence. That happens to me, too.

Stubborn Problem Solving:
1. You are sadly misunderstanding the problem. YOU are at fault!
2. Find 3 different interpretations to the problem.
3. Also, find 3 different OTHER places where it may cause the problem.
4. Consult the manual for help.

It may help to pretend that you're a newbie who doesn't understand everything. Don't laugh. It works! I used that technique myself occasionally. For the next level you must first admit that you are stupid. No, really. You are! You may humbly ask other people for help. Ever seen somebody arrogantly ask for solution to their problem? That never gets resolved, does it? Bingo.

Impossible Problem Solving:
1. Explain What the Problem is
2. Tell what you think are the relevant elements
3. Show what you did to solve the problem
4. WRITE THE SIMPLEST, SHORTEST CODE to explain the problem.

That last element is vital. No one wants to read 200 lines of code just to debug your program. So, there. Problem solving explained. Either that or you explain your problem to a duck.

Haha, joking aside, the ability to properly explain your problem is crucial in getting it solved. You don't want to ask a question like a grade schooler if you can ask your questions like a professor!

My PRINT doesn't work!

1. Did you type it in RUN(direct) mode or EDIT (deferred) mode?
2. Did it give you Syntax Error?
3. Did it print 0?
4. Did you set VISIBILITY?

What if PRINT doesn't work because it was set to XOR Mode? How will you respond to that? You can't set Console to XOR mode, right? How does that work? This is where giving out sample code is crucial.

CLS
COLOR SET XOR ! DOIT
PRINT "HELLO WORLD"

SET and DOIT ARE not keywordS. Why is there an exclamation mark preceding it? Because when I put it after the word (DOIT!), the computer complained, DUH!

You see how sample source code clarifies the issue quickly and easily? Don't act like a grade schooler. Ask questions like a professor! When I see the words "I don't understand ..." it'd better be followed by "These are the things I tried in order to understand it."