Monday:
too yellow...
Tuesday:
too red...
Wednesday:
too purple...
Thursday:
too blue ...
Friday:
too green ....
Saturday:
just right! And that's enough painting for this year.
20160709
20160305
Linux on the Ockel Sirius B - part 2
It works!
Use the EUFI update that is included with the Ubuntu instructions on http://www.ockelproducts.com/support/#a6857fbe0003d9f3e to convert to a 64 bit UEFI. Now you can install a normal distro. Running Fedora Core 23, to get wireless working i did a modprobe on brcmfmac. I also copied the firmware from the Ockel website, not sure if that is required.
Use the EUFI update that is included with the Ubuntu instructions on http://www.ockelproducts.com/support/#a6857fbe0003d9f3e to convert to a 64 bit UEFI. Now you can install a normal distro. Running Fedora Core 23, to get wireless working i did a modprobe on brcmfmac. I also copied the firmware from the Ockel website, not sure if that is required.
20160304
Linux on the Ockel Sirius B - part 1
Initially i thought this was going to be easy, unfortunately all distros i tried to boot from gave me exactly the same result: EUFI 32bit shell. Never ever booted from the usb stick.
Finally found these two posts:
Copied Debian Multiarch 8 on a usb stick using dd (from http://cdimage.debian.org/debian-cd/current/multi-arch/iso-dvd/ )
Switch off secure boot.
So now for the first time i got past the eufi shell!
Install runs ok, didn't find a network device (should be wireless), boots but doesn't go into graphics. Log in and startx doesn't seem to make it very happy: looks like the graphics mode is on,but still shows the prompt. Not that it does anything. I can switch to other terminal using ctrl+alt+Fx.
Update: saw that there is info on the Ockel website on how to do this: http://www.ockelproducts.com/support/#a6857fbe0003d9f3e will give that a shot later!
Finally found these two posts:
- https://blogs.intel.com/evangelists/2015/07/22/why-cheap-systems-run-32-bit-uefi-on-x64-systems/
- http://blogs.intel.com/evangelists/2015/08/11/update-on-ia32-uefi-and-linux-support/
Copied Debian Multiarch 8 on a usb stick using dd (from http://cdimage.debian.org/debian-cd/current/multi-arch/iso-dvd/ )
Switch off secure boot.
So now for the first time i got past the eufi shell!
Install runs ok, didn't find a network device (should be wireless), boots but doesn't go into graphics. Log in and startx doesn't seem to make it very happy: looks like the graphics mode is on,but still shows the prompt. Not that it does anything. I can switch to other terminal using ctrl+alt+Fx.
Update: saw that there is info on the Ockel website on how to do this: http://www.ockelproducts.com/support/#a6857fbe0003d9f3e will give that a shot later!
20140719
Riding to work with the Rubbee
First i did a test run last Sunday to the office (approx 15 miles) and after a short break back again:
The Rubbee starts to run with much less resistance than when it was new, hope this continues to improve as it slows you down quite a bit. that's the reason for taking it off the wheel on the downhill sections, the cost is about two minutes each time and you have to slowback, wait for a gap between cars before you can accelerate.
Number of stops:
55 minutes each way sounds tempting... can the Rubbee do it or do i need a real electric mountain bike. I'd need to leave the car and the the ebike a thousand times to break even ... need to find a better reason than just financial i guess.
- to work 70 minutes
- back home 70 minutes
- only put the Rubbee on the wheel for the uphill sections, so had still a little bit spare when i got home
- very nice ride: cloudy with 2 minutes of drizzle when i started out, sunny by the time i got to the office. Could have done with more water. No backpack.
- on wet sections the noise the Rubbee made was quite bad ... slipping over the knobbly bits of the tire i guess.
- to work 66 minutes, ran out of power just before the office (200m)
- back home 64 minutes, ran out of power about a mile from home
- using the Rubbee almost 75% of the time, only taking it off the wheel for the downhill sections
- couldn't get my rhythm until i was almost at the office, just not used to exercise that early in the morning i guess...
- cooler than Sumday on the way back
- my front light warns that it's getting low on power after about 40 minutes by switching the indicator from green to orange, it is however still bright at the end of ride
- also changed from knobbly tires to road tires (for a second i was tempted to go for near slicks ... but the roads are pretty bad so i went for a bit more sensible ones.
- first time with a backpack, may also have contributed to the not so pleasant ride in, i haven't ridden with a backpack for ages.
- to work 68 minutes
- back home 67 minutes
- much better rider in, despite the roads being wet and me getting rather muddy,
- the way back was harder as it was hot! The backpack did not help...
- drawback in the wet was that the Rubbee started slipping when i put on more power (seemed ok to keep the same speed).
- forgot the recharge the front light, got home and it was still orange (and quite bright)
The Rubbee starts to run with much less resistance than when it was new, hope this continues to improve as it slows you down quite a bit. that's the reason for taking it off the wheel on the downhill sections, the cost is about two minutes each time and you have to slowback, wait for a gap between cars before you can accelerate.
Number of stops:
- five on the way to work (for Wednesday and Friday)
- four on the way back (again Wednesday and Friday only)
55 minutes each way sounds tempting... can the Rubbee do it or do i need a real electric mountain bike. I'd need to leave the car and the the ebike a thousand times to break even ... need to find a better reason than just financial i guess.
20140506
Never lose the locking pin on my Rubbee again!
On a long down hill section (public road in Surrey, rather bumpy due to the potholes) i had my Rubbee off the back wheel. And at the bottom it was on my wheel ... somewhere along the way i'd lost the locking pin (and i wasn't in the mood to cycle back up).
Never again! Here is my solution (ignore the yellow bits, that clip is just temporary until i find the one i want to use again... same for the temporary 'locking pin', i'm not going to ride with that!):
Clip it through the ring of the locking pin, so that if it falls out again i can just pop it back in.
Never again! Here is my solution (ignore the yellow bits, that clip is just temporary until i find the one i want to use again... same for the temporary 'locking pin', i'm not going to ride with that!):
Clip it through the ring of the locking pin, so that if it falls out again i can just pop it back in.
20140106
Accessing IR-Blue-DM from linux
Note: do the initial tests with the bluetooth dongle straight on the machine (Udoo in my case) instead of plugged in a hub. Scanning works on a hub but for some reason rfcomm doesn't connect very often if the dongle is on a hub.
Quick hack #1:
Check if we can see the device:
root@imx6-qsdl:/home/ubuntu# hcitool scanScanning ...
EC:FE:xx:xx:xx:xx IR-Blue-DM
Same using LE:
root@imx6-qsdl:/home/ubuntu# hcitool lescan
LE Scan ...
EC:FE:xx:xx:xx:xx
Check if we need a pin:
root@imx6-qsdl:/home/ubuntu# bluez-simple-agent hci0 EC:FE:xx:xx:xx:xx
Release
New device (/org/bluez/5683/hci0/dev_EC_FE_xx_xx_xx_xx)
Seems we don't need one, connect using rfcomm.
root@imx6-qsdl:/home/ubuntu# rfcomm connect hci0 EC:FE:xx:xx:xx:xx
Connected /dev/rfcomm0 to EC:FE:xx:xx:xx:xx on channel 1
Press CTRL-C for hangup
^CDisconnected
See if there is any data:
root@imx6-qsdl:/home/ubuntu# cat /dev/rfcomm0
And after you do 'echo >/dev/rfcomm0 "R001\r\n"' in another terminal there is data!:
E211208208208215214212212218220218213222223221218223223221216224225223220227226225222226227225223228228227225229229228225229228229228229230230228230230229230230230231230230230229229227229227227188188188188205205196196205205205196205205205205213205205205205213205205213213213205213213213205213213222213222222222213222222222222222222222222222222222222222222222222222222222222213222222222 0 17 17 10 41 62 62 52 79 86 96 90103121124107131152159138159162169148169183183155179186186162179193193159176190190165176186183148172172176131151158158120124138145 96103107110 65 69 75 68 23255255255255255255255255255255 0 0 0 0 0 0 0 0 0216221205 0 0 0 8150 26 17 93105 36230 79 40 34 0128 0 0255 33 0188 26190 59 25245 27150 26255 30116 91166 32136 44 10 33 1 26EX
R144006836145-00045I -54 -54 -52 -54 -53 -54 -51 -50 -52 -50 -52 -49 -50 -50 -49 -47 -51 -51 -51 -49 -52 -50 -50 -48 -48 -50 -45 -47 -45 -43 -42 -44 -41 -42 -43 -45 -27 -41 -43 -44 -40 -41 -41 -43 -42 -42 -42 -42 -44 -43 -43 -42 -42 -43 -42 -42 -42 -41 -42 -40 -42 -42 -42 -41X
Quick hack #2:
Use a small python routine to read data:
import serial
import time
ser=serial.Serial("/dev/rfcomm0", baudrate=57600,timeout=0.1)
ser.open()
ser.write("R001"+chr(13)+chr(10))
while (1==1):
d=ser.readline()
print len(d),d
Success! Now to write something that gets temperature values and shows the result graphically...
I found the R001 command in the android code on http://github.com/RHWorkshop , the H command can be used to increase the speed at which the data is sent.
Quick hack #1:
Check if we can see the device:
root@imx6-qsdl:/home/ubuntu# hcitool scanScanning ...
EC:FE:xx:xx:xx:xx IR-Blue-DM
Same using LE:
root@imx6-qsdl:/home/ubuntu# hcitool lescan
LE Scan ...
EC:FE:xx:xx:xx:xx
Check if we need a pin:
root@imx6-qsdl:/home/ubuntu# bluez-simple-agent hci0 EC:FE:xx:xx:xx:xx
Release
New device (/org/bluez/5683/hci0/dev_EC_FE_xx_xx_xx_xx)
Seems we don't need one, connect using rfcomm.
root@imx6-qsdl:/home/ubuntu# rfcomm connect hci0 EC:FE:xx:xx:xx:xx
Connected /dev/rfcomm0 to EC:FE:xx:xx:xx:xx on channel 1
Press CTRL-C for hangup
^CDisconnected
See if there is any data:
root@imx6-qsdl:/home/ubuntu# cat /dev/rfcomm0
And after you do 'echo >/dev/rfcomm0 "R001\r\n"' in another terminal there is data!:
E211208208208215214212212218220218213222223221218223223221216224225223220227226225222226227225223228228227225229229228225229228229228229230230228230230229230230230231230230230229229227229227227188188188188205205196196205205205196205205205205213205205205205213205205213213213205213213213205213213222213222222222213222222222222222222222222222222222222222222222222222222222222213222222222 0 17 17 10 41 62 62 52 79 86 96 90103121124107131152159138159162169148169183183155179186186162179193193159176190190165176186183148172172176131151158158120124138145 96103107110 65 69 75 68 23255255255255255255255255255255 0 0 0 0 0 0 0 0 0216221205 0 0 0 8150 26 17 93105 36230 79 40 34 0128 0 0255 33 0188 26190 59 25245 27150 26255 30116 91166 32136 44 10 33 1 26EX
R144006836145-00045I -54 -54 -52 -54 -53 -54 -51 -50 -52 -50 -52 -49 -50 -50 -49 -47 -51 -51 -51 -49 -52 -50 -50 -48 -48 -50 -45 -47 -45 -43 -42 -44 -41 -42 -43 -45 -27 -41 -43 -44 -40 -41 -41 -43 -42 -42 -42 -42 -44 -43 -43 -42 -42 -43 -42 -42 -42 -41 -42 -40 -42 -42 -42 -41X
Quick hack #2:
Use a small python routine to read data:
import serial
import time
ser=serial.Serial("/dev/rfcomm0", baudrate=57600,timeout=0.1)
ser.open()
ser.write("R001"+chr(13)+chr(10))
while (1==1):
d=ser.readline()
print len(d),d
Success! Now to write something that gets temperature values and shows the result graphically...
I found the R001 command in the android code on http://github.com/RHWorkshop , the H command can be used to increase the speed at which the data is sent.
20130824
Teamviewer - using aliases
I really like teamviewer (free for personal use), after creating an account and running it on most of my machines and my android tablet the one thing i couldn't find easily figure out was why one of my machines had a human readable name and all the others showed up with just the teamviewer id.
The annoying thing is that only the machine with the human readable name has an option to change its properties and the others only allow me to connect to them. Googled for an answer for ages, must be a typical case of me searching using the wrong keywords or nobody else trying to do this...
Finally after messing around for ages i found that i had to add the machines manually in computers and contacts (not logical as they're in my list already...), then you get the option to add an alias (grumble: why do have to type in the teamviewer id - would like to see a rightclick option for that).
Great now i'll be able to connect to the correct machine in one go without having to memorize the teamview id.
As a 'benefit' the machines are now listed twice: directly in the 'my computer' list and once under my account. And there must be some logic as to why the machines show up yellow (idle) under the account but green (active) in the 'my computer' list.
The annoying thing is that only the machine with the human readable name has an option to change its properties and the others only allow me to connect to them. Googled for an answer for ages, must be a typical case of me searching using the wrong keywords or nobody else trying to do this...
Finally after messing around for ages i found that i had to add the machines manually in computers and contacts (not logical as they're in my list already...), then you get the option to add an alias (grumble: why do have to type in the teamviewer id - would like to see a rightclick option for that).
Great now i'll be able to connect to the correct machine in one go without having to memorize the teamview id.
As a 'benefit' the machines are now listed twice: directly in the 'my computer' list and once under my account. And there must be some logic as to why the machines show up yellow (idle) under the account but green (active) in the 'my computer' list.
Subscribe to:
Posts (Atom)