Woo-hoo!
Today I booked my flight back to Canada on the 14th of March, from Hamburg to Montréal. Can you tell that I have a huge smile on my face as I write this? Hehehe..
In the next month, I'll be writing my exams in Advanced Signals & Systems, Advanced Digital Signal Processing, and then I'm organizing to write my exam in Digital Communications at McGill via some awesome department that will proctor exams for external universities ;-) I've never even heard of that before.
But hey, if it means that I don't miss out on an exam and I get to be in my new apartment with my lady friend and Julien, then that's entirely wicked in my opinion!
Oh yes, and by the way, version 2.0 will be named Julien Jacob Friedt - although I'm not 100% sure of the spelling of all of it - Erin and I both agree that Julien should be with an 'e', but I sort of feel like using a 'k' in Jakob just because that's how they would spell it over here.
By the way, if anyone feels like buying a few baby clothes, these ones are definitely on the wish list:
http://www.thinkgeek.com/tshirts/kids/5ace/
http://www.thinkgeek.com/tshirts/kids/59cc/
http://www.thinkgeek.com/tshirts/kids/6c71/
and my personal favorite
http://www.thinkgeek.com/tshirts/kids/9b11/
Sigh, comic relief ;-)
I spoke to Sammy D.J. just yesterday, and He and Emily are also expecting a newcomer in July - Ethan Donald. Dwayne Williams also has one (or two) little ones already, and countless numbers of others must be married at this point - jeez, I'm starting to sound like a 30 year old! AAAAGGHH!!
It seems as if it were yesterday that we were wearing hospital pants and hardhats and getting completely $h17-faced in the 4th floor of Pitman Hall. I know, I'm a bit of a sentimental, but hey - what a wild time; the nights without sleep studying for exams, practically living in the basement of the building formerly known as T... sometimes I can't even believe that I'm here in Germany now doing my master's. I'm meeting so many people from all over the world - I hope I stay good friends with all of them, just because having friends in other countries just makes the best excuse to travel ;-)
Speaking of travel, the feeling that I will be 'going home' to Montréal hasn't even really sunk in yet. What I mean, is that it seems like I've been renting rooms for literally the last decade of my life! Moving from city to city, province to province, country, continent, etc. Now Erin & I are pretty much starting out together in a beautiful plateau apartement à côté du Parc LaFontaine. I can't wait! The next year of my life is going to be full of the most amazing experiences.
Well, I'd better get back to work / studying
Hasta Luego
20080218
MaverickCrunch / EABI Toolchain, Kernel, and Sysroot
Hi everyone,
I just announced a somewhat lengthy HowTo with information on building a fully compliant kernel, root filesystem, and toolchain for use with the ep93xx series of SOC's. This is really mainly addressed at Gentoo Linux users due to the build system in place.
GentooWiki:Gentoo_for_the_TS72xx_SBC_(Full_Distro)
The next few steps are getting a package manager working, a commissioning station, and also a database for storing client/host keys.
20080211
Follow Up to EABI / Maverick Userland
Hi Everyone,
I left off with instructions for creating an eabi / maverick toolchain for the ts72xx boards from EmbeddedARM.com, and am still sifting my way through some pretty dense decisions.
First of all, Gentoo's Portage build system makes it really easy to cross-compile packages and maintain dependencies. I think it's fantastic. The ony tricky part is in how the package database is maintained on-board. It's not even a database actually, it's right in the filesystem. Depending on the block size, even a 2-byte file could take up 4 kB of space, which is way beyond anything conceptual for an on-board package database for embedded devices.
I've considered writing in some sqlite code into the 'qmerge' app that comes with portage-utils. The benefit is that the sqlite file would save potentially doezens of kB of space. Furthermore, the sqlite file could be compressed in the filesystem after updates have taken place. When any package maintenance needs to be done, the sqlite database could be extracted to a tmpfs-mounted directory, and all of the operations could be performed there.
An alternative to that, is actually just to use the current filesystem-based package db and simply compress that directory without the sqlite backend. Then when updates were necessary, it would be possible to extract that to tmpfs, and re-compress when done.
Time is of the essence on my latest project, so it's likely that I won't be able to fully code that into portage-utils until my current project is matured and nearing completion. The matured stage is probably 1 month from now, and the completion stage is probably closer to 2 months away.
I'll post my instructions, as planned on gentoo-wiki.com for doing cross-compilation and building up to a certain stage, but more instructions on how to maintain packages on a live system may be delayed for some time.
I left off with instructions for creating an eabi / maverick toolchain for the ts72xx boards from EmbeddedARM.com, and am still sifting my way through some pretty dense decisions.
First of all, Gentoo's Portage build system makes it really easy to cross-compile packages and maintain dependencies. I think it's fantastic. The ony tricky part is in how the package database is maintained on-board. It's not even a database actually, it's right in the filesystem. Depending on the block size, even a 2-byte file could take up 4 kB of space, which is way beyond anything conceptual for an on-board package database for embedded devices.
I've considered writing in some sqlite code into the 'qmerge' app that comes with portage-utils. The benefit is that the sqlite file would save potentially doezens of kB of space. Furthermore, the sqlite file could be compressed in the filesystem after updates have taken place. When any package maintenance needs to be done, the sqlite database could be extracted to a tmpfs-mounted directory, and all of the operations could be performed there.
An alternative to that, is actually just to use the current filesystem-based package db and simply compress that directory without the sqlite backend. Then when updates were necessary, it would be possible to extract that to tmpfs, and re-compress when done.
Time is of the essence on my latest project, so it's likely that I won't be able to fully code that into portage-utils until my current project is matured and nearing completion. The matured stage is probably 1 month from now, and the completion stage is probably closer to 2 months away.
I'll post my instructions, as planned on gentoo-wiki.com for doing cross-compilation and building up to a certain stage, but more instructions on how to maintain packages on a live system may be delayed for some time.
20080203
More Maverick/EABI fun ;-)
I've just finished cross-compiling an entire root filesystem from scratch for the TS72xx boards with the EABI and it's working out very well! The softfp floating-point ABI has indeed shown a dramatic increase in speed! I've tested out using emqbit-bench and the performance improvements match those found in the article "Why ARM's EABI Matters". I haven't yet been able to try out some hard floating point calculations, such as those done by Martin Guy, but hopefully I'll get to that soon.
The entire HowTo is written up right now and I've tested the procedure with both the arm-softfloat-linux-gnu toolchain/kernel/filesystem and the armv4t-maverick-linux-gnueabi toolchain/kernel/filesystem.
The kernel config /patches are working perfectly for linux-2.6.23.1 . I should have an article up on Gentoo-Wiki.com specifically assisting TS-72xx users in creating a manageable build environment for their boards.
After I get the article up, my next goal will be to determine a suitable binary package manager for live system updates. Thus far, I've looked at Paludis and iPkg [ 20080207 Update: ] and Qmerge which is one of the 'q' tools that comes with app-portage/portage-utils.
After reading an interview with Ciaran McCreesh, I've really gained an appreciation for what Paludis is doing with ebuild syntax modification. Some of those modifications are just so intuitive, convenient, and easily implemented, that I really wish they were already in Gentoo's Portage system. Actually, the article explains in some detail why that isn't already the case.
Paludis also requires a C++ runtime, just because it would have been quite difficult to code it entirely in C, although a rewrite is still possible I suppose. I'd rather not get into C++ right now on production systems. Also it seems that there is still a dependency for the entire portage / paludis ebuild tree to reside on the host, and that is definitely not happening.
On the other hand, iPkg has been in use for quite some time for embedded Linux package management and takes up only a few tens of kilobytes. It's recently been completely rewritten in C, which is fantastic news.
If I were to go with iPkg, then the other issue would be in conversion between Gentoo's tbz2 binary package format and iPkg's .ipkg binary format. Such a converter exists, but still requires some fine tuning.
[ 20080207 Update1: ] I've 95% decided to go with qmerge as my preferred on-board package manager. There are only a few things I need to check out before I go ahead with it fully. Namely, I need to do some test to make sure that it maintains a package database as I would expect, and that it can somehow report exact package versions when told to list installed packages (that might require some work on my part).
[ 20080207 Update2: ] Oh Gawd! Gentoo strikes again... I swear, I've never known a distro that so vagrantly throws around resources as if they were nothing... I think the dependency on /var/db/pkg might have bj@rkskt my idea of using qmerge as an embedded package manager. I'd rather not have to do any feature-adding if i can avoid it... qmerge was 95 percent there... maybe I should just write in some sqlite code and get it over with... I wonder how much that would actually improve things, if at all.
What puzzles me these days about all of the different Linux distro's having different package managers, is that the fundamental issue that they're all trying to solve is the same. Some of them handle that issue better than others, some of them lack certain features that others have, and some lean toward binary package distribution more than others (actually most). Fundamentally, the entire problem lies in solving dependency issues and tieing that together with the package database.
With embedded systems, the size of the package DB has to be extremely small, or else it needs to be maintained off-board.
[ Update 20080207: ] I think that I might be mistaken on the size of the portage db - it's much larger than expected!! For instance du -hs /var/db/pkg/net-wireless/wireless-tools is 128 kB !! That's WAY too big. Maybe I'm looking in the wrong place here - was I wrong to expect an actual database and not a filesystem for recording all of the relevent package information?
The entire HowTo is written up right now and I've tested the procedure with both the arm-softfloat-linux-gnu toolchain/kernel/filesystem and the armv4t-maverick-linux-gnueabi toolchain/kernel/filesystem.
The kernel config /patches are working perfectly for linux-2.6.23.1 . I should have an article up on Gentoo-Wiki.com specifically assisting TS-72xx users in creating a manageable build environment for their boards.
After I get the article up, my next goal will be to determine a suitable binary package manager for live system updates. Thus far, I've looked at Paludis and iPkg [ 20080207 Update: ] and Qmerge which is one of the 'q' tools that comes with app-portage/portage-utils.
After reading an interview with Ciaran McCreesh, I've really gained an appreciation for what Paludis is doing with ebuild syntax modification. Some of those modifications are just so intuitive, convenient, and easily implemented, that I really wish they were already in Gentoo's Portage system. Actually, the article explains in some detail why that isn't already the case.
Paludis also requires a C++ runtime, just because it would have been quite difficult to code it entirely in C, although a rewrite is still possible I suppose. I'd rather not get into C++ right now on production systems. Also it seems that there is still a dependency for the entire portage / paludis ebuild tree to reside on the host, and that is definitely not happening.
On the other hand, iPkg has been in use for quite some time for embedded Linux package management and takes up only a few tens of kilobytes. It's recently been completely rewritten in C, which is fantastic news.
If I were to go with iPkg, then the other issue would be in conversion between Gentoo's tbz2 binary package format and iPkg's .ipkg binary format. Such a converter exists, but still requires some fine tuning.
[ 20080207 Update1: ] I've 95% decided to go with qmerge as my preferred on-board package manager. There are only a few things I need to check out before I go ahead with it fully. Namely, I need to do some test to make sure that it maintains a package database as I would expect, and that it can somehow report exact package versions when told to list installed packages (that might require some work on my part).
[ 20080207 Update2: ] Oh Gawd! Gentoo strikes again... I swear, I've never known a distro that so vagrantly throws around resources as if they were nothing... I think the dependency on /var/db/pkg might have bj@rkskt my idea of using qmerge as an embedded package manager. I'd rather not have to do any feature-adding if i can avoid it... qmerge was 95 percent there... maybe I should just write in some sqlite code and get it over with... I wonder how much that would actually improve things, if at all.
What puzzles me these days about all of the different Linux distro's having different package managers, is that the fundamental issue that they're all trying to solve is the same. Some of them handle that issue better than others, some of them lack certain features that others have, and some lean toward binary package distribution more than others (actually most). Fundamentally, the entire problem lies in solving dependency issues and tieing that together with the package database.
With embedded systems, the size of the package DB has to be extremely small, or else it needs to be maintained off-board.
[ Update 20080207: ] I think that I might be mistaken on the size of the portage db - it's much larger than expected!! For instance du -hs /var/db/pkg/net-wireless/wireless-tools is 128 kB !! That's WAY too big. Maybe I'm looking in the wrong place here - was I wrong to expect an actual database and not a filesystem for recording all of the relevent package information?
20080201
Maverick-Crunch / EABI support for Crossdev
Since I've been using the TS-7xxx boards from Technologic Systems, I've been wanting to experiment a bit more with the Maverick-Crunch floating point coprocessor in order to squeeze a bit more performance in number-crunching apps.
Here are some simple instructions for creating an armv4tl-maverick-linux-gnueabi toolchain using Gentoo/Portage/Crossdev. These instructions are current as of 26. February 2008.
[ Update: 26. Feb, 2008 ]
The procedure is tested and I have yet to experience any bugs in any normal userspace applications. I know that lame now produces mp3s 25 times faster, and there were no audible errors, which basically confirms with Martin Guy's results that the Maverick FPU is being used.
The only thing that I am lacking is a better stress test - paranoia.c just segfaults, and I'm not really sure why.
I've moved the instructions, as well as instructions for creating an eabi Linux kernel and a full userland, to the Gentoo Wiki.
20080129
WiFi in the TF
Ok, forget completely about xsupplicant - it's horribly written software. I had to correct several sections of code just so it would compile, and then I later realized that it was truncating the ESSID string to an improper length.
I managed to get WPA-EAP / EAP-TLS working with wpa_supplicant, and it wasn't so hard after all.
Requirements:
You should have been given 4 files from the TF administrator - Root.der, Client.der, Server.der, and xyz.p12, where xyz is your username. You should also know your passphrase.
You should have wpa_supplicant installed (it should pull in OpenSSL as a requirement). If you don't have wpa_supplicant installed, then do 'emerge -av1 wpa_supplicant'.
Important: Do not install wpa_supplicant with the gnutls USE flag; gnutls has a broken implementation of eap-tls right now, resulting in errors such as
Steps:
1) Switch to the root user. Copy all 4 files to /etc/wpa_supplicant.
sudo -s
mkdir -p /etc/wpa_supplicant # should be created by wpa_supplicant
cp Root.der Client.der Server.der xyz.p12 /etc/wpa_supplicant
2) According to 'man wpa_supplicant',
cd /etc/wpa_supplicant
for i in Root Server Client; do
openssl x509 -inform DER -in ${i}.der -out ${i}.pem
done
When converting your public / private key from pkcs12 format above, it will ask you for an 'Import Password', which is null. Simply hit enter. Next it will ask you for your PEM passphrase, which is the one you should already be familiar with.
3) From 'man wpa_supplicant.conf', append the following to /etc/wpa_supplicant/wpa_supplicant.conf :
# Technische Fakultaet
network={
ssid="TFconnect"
key_mgmt=IEEE8021X
eap=TLS
identity="xyz"
ca_cert="/etc/wpa_supplicant/Root.der"
ca_path="/etc/wpa_supplicant/"
private_key="/etc/wpa_supplicant/xyz.pem"
client_cert="/etc/wpa_supplicant/xyz.pem"
private_key_passwd="your secret passphrase"
eapol_flags=3
}
4) Now use your common method of starting wpa_supplicant. I assume your wireless device is called wlan0, but sometimes it's simply called eth1. For Gentoo, I do
cd /etc/init.d
ln -sf net.lo net.wlan0
5) The -D argument can vary. Mine is wext, but yours could be madwifi or madwifi-ng. Add something like the following to /etc/conf.d/net, if you don't already have a configuration for wpa_supplicant.
modules_wlan0=( "wpa_supplicant" "dhcpcd" )
wpa_supplicant_wlan0=( "-D wext -c /etc/wpa_supplicant/wpa_supplicant.conf" )
6) Lastly, run
/etc/init.d/net.wlan0 restart
I managed to get WPA-EAP / EAP-TLS working with wpa_supplicant, and it wasn't so hard after all.
Requirements:
You should have been given 4 files from the TF administrator - Root.der, Client.der, Server.der, and xyz.p12, where xyz is your username. You should also know your passphrase.
You should have wpa_supplicant installed (it should pull in OpenSSL as a requirement). If you don't have wpa_supplicant installed, then do 'emerge -av1 wpa_supplicant'.
Important: Do not install wpa_supplicant with the gnutls USE flag; gnutls has a broken implementation of eap-tls right now, resulting in errors such as
- "Failed to read client cert/key in PEM format: Base64 unexpected header error"
- "Failed to read client cert/key in DER format: ASN1 parser: Error in TAG."
Steps:
1) Switch to the root user. Copy all 4 files to /etc/wpa_supplicant.
sudo -s
mkdir -p /etc/wpa_supplicant # should be created by wpa_supplicant
cp Root.der Client.der Server.der xyz.p12 /etc/wpa_supplicant
2) According to 'man wpa_supplicant',
"Wpa_supplicant supports X.509 certificates in PEM and DER formats. User certificate and private key can be included in the same file. If the user certificate and private key is received in PKCS#12/PFX format, they need to be converted to suitable PEM/DER format."
cd /etc/wpa_supplicant
for i in Root Server Client; do
openssl x509 -inform DER -in ${i}.der -out ${i}.pem
done
openssl pkcs12 -in xyz.p12 -out xyz.pem -clcerts
# we do not want anyone reading / modifying the keys aside from root
chmod u+rw,go-rwx {Root,Server,Client}.{der,pem} xyz.{p12,pem}
When converting your public / private key from pkcs12 format above, it will ask you for an 'Import Password', which is null. Simply hit enter. Next it will ask you for your PEM passphrase, which is the one you should already be familiar with.
3) From 'man wpa_supplicant.conf', append the following to /etc/wpa_supplicant/wpa_supplicant.conf :
# Technische Fakultaet
network={
ssid="TFconnect"
key_mgmt=IEEE8021X
eap=TLS
identity="xyz"
ca_cert="/etc/wpa_supplicant/Root.der"
ca_path="/etc/wpa_supplicant/"
private_key="/etc/wpa_supplicant/xyz.pem"
client_cert="/etc/wpa_supplicant/xyz.pem"
private_key_passwd="your secret passphrase"
eapol_flags=3
}
4) Now use your common method of starting wpa_supplicant. I assume your wireless device is called wlan0, but sometimes it's simply called eth1. For Gentoo, I do
cd /etc/init.d
ln -sf net.lo net.wlan0
5) The -D argument can vary. Mine is wext, but yours could be madwifi or madwifi-ng. Add something like the following to /etc/conf.d/net, if you don't already have a configuration for wpa_supplicant.
modules_wlan0=( "wpa_supplicant" "dhcpcd" )
wpa_supplicant_wlan0=( "-D wext -c /etc/wpa_supplicant/wpa_supplicant.conf" )
6) Lastly, run
/etc/init.d/net.wlan0 restart
20080120
Python is Pissing Me Off
For the record, I just want to say that I hate Python at this very moment. In fact, I downright loathe it.
FIX THE FSCKING BUILD SCRIPT FOR CROSS BUILDING ALREADY!
FIX THE FSCKING BUILD SCRIPT FOR CROSS BUILDING ALREADY!
20071128
All I Want for Christmas
Christmas is a stressful time for me. Mainly because it involves transporting myself back home, and doing last minute Christmas shopping. For the last two years that's involved taking a last minute flight over the Atlantic. I haven't had very much time to get a haircut, let alone go Christmas shopping. I wish I could say that I've been thinking about giving gifts all year, and figured-out exactly the right gift to give to each of my relatives. The truth is, I haven't.
Mainly during the times when I've been a student, I haven't found the excitement over giving or receiving gifts at Christmas. Maybe that's because I've been historically fairly broke for the holidays, or maybe it's because I've gone through the entire year without any major hankerings because I've been too busy! Who knows. I usually get more excited when I give gifts.
While I've been a student, I find it great just having an excuse and having the ability to get together with family in mass quantities for the holidays ;-)
With a new baby on the way in May, I'm sure that many of my relatives will be giving me lots of 'stuff' for Christmas. I assure you, I will very likely have no place to put anything, and I definitely will not be bringing anything with me back to Germany. Maybe hold off on the 'stuff' buying until March or so. As it stands, I have 3 good suitcases full of 'stuff' that I will need to somehow transport back to Canada before March. I would also have no place to put it in Canada and my storage space there is already aux gratis and running out.
This year, the only gifts I would imagine receiving are small chunks of money that I would hope to put toward an education fund for our new arrival in May.
And maybe a video collection of works by Bob Ross :) I've always thought his show was super relaxing to watch.
And now, back to the joy of programming :)
Mainly during the times when I've been a student, I haven't found the excitement over giving or receiving gifts at Christmas. Maybe that's because I've been historically fairly broke for the holidays, or maybe it's because I've gone through the entire year without any major hankerings because I've been too busy! Who knows. I usually get more excited when I give gifts.
While I've been a student, I find it great just having an excuse and having the ability to get together with family in mass quantities for the holidays ;-)
With a new baby on the way in May, I'm sure that many of my relatives will be giving me lots of 'stuff' for Christmas. I assure you, I will very likely have no place to put anything, and I definitely will not be bringing anything with me back to Germany. Maybe hold off on the 'stuff' buying until March or so. As it stands, I have 3 good suitcases full of 'stuff' that I will need to somehow transport back to Canada before March. I would also have no place to put it in Canada and my storage space there is already aux gratis and running out.
This year, the only gifts I would imagine receiving are small chunks of money that I would hope to put toward an education fund for our new arrival in May.
And maybe a video collection of works by Bob Ross :) I've always thought his show was super relaxing to watch.
And now, back to the joy of programming :)
20071118
IEEE.tv Article Interviews John Stevens
John Stevens, CEO of Visible Assets, was recently featured in an interview at the RFID conference in Dallas. Actually, the conference took place 26-28 March, 2007. I only just noticed the interview because I started subscribing to IEEE.tv through Mozilla Thunderbird's RSS news reader. I also happen to work for Visible Assets, and so I thought I'd take this opportunity for some shameless corporate promotion :)
In the interview, John explains some of the details about RuBee(tm), the pending IEEE protocol (IEEE P1902.1), and how Visible Assets applies the relatively young technology of long-wavelength radio tags. At Visible Assets, we basically sell a service that builds upon RuBee(tm). Through the grouping of distributed, collaborative, and localized networkable transceivers, RuBee(tm) securely enables the authorized end user to asynchronously monitor their assets from anywhere in the world. All communication between the transceivers and the end user are event-based, which cuts down on bandwidth over long distances, enabling local monitoring in real-time and remote monitoring with extremely low latency.
RuBee(tm) is protocol that can overlay the common IEEE 802 standard. What that means in human terms, is that every tag can be assigned an IP address, just like the computer on which you read this article. When IPV6 takes over, boasting an addressable space of 2128 (about 3.4×1038), that means that every single tag will have a globally visible, unique address on the internet. Pretty astonishing, isn't it.
If I slapped a tag on my favorite toothbrush, flew to Japan, and visited an internet cafe, I have the potential to be disappointed that I forgot my favorite toothbrush on the other side of the planet. But hey, at least I would know that it was safe and sound back home ;-) That's really a crude example. Our primary clients are those who need high data reliability when monitoring their assets, such as those in the medical, pharmaceutical, agricultural, and defense sectors.
RuBee(tm) is the main feature of our infrastructure. Therefore, I should take the opportunity to share some information about the unique technology that we, at Visibile Assets, bring to the RFID spectrum.
Our tags do not belong in the same category as RFID, although they could conceptually be used in many of the same situations where RFID is used today. It should be noted that our tags operate at the lowest end of the RF spectrum (below 450 kHz), and should therefore be considered a complement to RFID. This difference in carrier frequency results in some fundamental contrasts between our tags and conventional RFID. Namely,
Currently I'm doing a master's degree in Digital Communications during the day, but then at night I assume the role of my secret identity as embedded systems engineer for Visible Assets. Right now I'm implementing a fairly sophisticated software stack in probably the best C code I've ever written in my life!! Needless to say, it keeps me reading up on all of the distributed / intelligent systems literature that I can get my hands on.
Nice interview John! I'm looking forward to showing you what's been keeping me so busy lately.
Other articles about what we do at Visible Asests:
Converge! Network Digest [20060609]:
IEEE Begins Work on Wireless, Long-Wavelength Standard
Sensors Specialty Markets [20060612]:
New Wireless Standard for Healthcare and Livestock Visibility Networks
RF GlobalNet [20060612]:
IEEE Begins Wireless, Long-Wavelength Standard for Low-Cost Radio Tags
RF Design [20060614]:
New IEEE standard to bring local network protocol to thousands of radio tags with long battery lives
RFID Journal [20060619]:
Visible Assets Promotes RuBee(tm) Tags for Tough to Track Goods
IDTechEx [20070208]:
IEEE RuBee(tm) Network Standard Meeting
Epson [20070507]:
Visible Assets, RuBee(tm) Technology Leader, Announces Investment from Epson Electronics America
In the interview, John explains some of the details about RuBee(tm), the pending IEEE protocol (IEEE P1902.1), and how Visible Assets applies the relatively young technology of long-wavelength radio tags. At Visible Assets, we basically sell a service that builds upon RuBee(tm). Through the grouping of distributed, collaborative, and localized networkable transceivers, RuBee(tm) securely enables the authorized end user to asynchronously monitor their assets from anywhere in the world. All communication between the transceivers and the end user are event-based, which cuts down on bandwidth over long distances, enabling local monitoring in real-time and remote monitoring with extremely low latency.
RuBee(tm) is protocol that can overlay the common IEEE 802 standard. What that means in human terms, is that every tag can be assigned an IP address, just like the computer on which you read this article. When IPV6 takes over, boasting an addressable space of 2128 (about 3.4×1038), that means that every single tag will have a globally visible, unique address on the internet. Pretty astonishing, isn't it.
If I slapped a tag on my favorite toothbrush, flew to Japan, and visited an internet cafe, I have the potential to be disappointed that I forgot my favorite toothbrush on the other side of the planet. But hey, at least I would know that it was safe and sound back home ;-) That's really a crude example. Our primary clients are those who need high data reliability when monitoring their assets, such as those in the medical, pharmaceutical, agricultural, and defense sectors.
RuBee(tm) is the main feature of our infrastructure. Therefore, I should take the opportunity to share some information about the unique technology that we, at Visibile Assets, bring to the RFID spectrum.
Our tags do not belong in the same category as RFID, although they could conceptually be used in many of the same situations where RFID is used today. It should be noted that our tags operate at the lowest end of the RF spectrum (below 450 kHz), and should therefore be considered a complement to RFID. This difference in carrier frequency results in some fundamental contrasts between our tags and conventional RFID. Namely,
- RFID has very short range with low penetration, while our tags have very high penetration and a considerably longer range,
- RFID electro-magnetic (wireless) signals are largely composed of electric (E) fields, while our tags contain 99% magnetic (B) fields
- RFID signals have a high bit-error-rate (BER), while our tags have a low BER
- RFID tags are generally passive devices, whereas our tags can be passive, or optionally active devices for wireless data-acquisition applications (temperature, pressure, etc)
Currently I'm doing a master's degree in Digital Communications during the day, but then at night I assume the role of my secret identity as embedded systems engineer for Visible Assets. Right now I'm implementing a fairly sophisticated software stack in probably the best C code I've ever written in my life!! Needless to say, it keeps me reading up on all of the distributed / intelligent systems literature that I can get my hands on.
In the interview, John really spells out a highly technical subject in such a way that the average layman can understand, which isn't a very common ability among engineers. Don't let that fool you though. There are only a few people who understand our technology through and through, and John is one of them.
That's only one of the reasons I really like working under him. John has a great relationship with all of his employees. Last year we had our staff Christmas party at his home, which is more of a personal touch than I've seen at any other company. He gave this great speech which was followed by a cheerful toast, and it really motivated me - I'm working on some pretty cool stuff!
John gets so excited when he finds out about new progress that we've made. The only analogy I can give is to compare him to a child with a new train set. He's always excited to figure out how things work and he loves talking about all of the development details, like what challenges we faced, where we made compromises, and new and interesting ways we've used to overcome obstacles.
That's only one of the reasons I really like working under him. John has a great relationship with all of his employees. Last year we had our staff Christmas party at his home, which is more of a personal touch than I've seen at any other company. He gave this great speech which was followed by a cheerful toast, and it really motivated me - I'm working on some pretty cool stuff!
John gets so excited when he finds out about new progress that we've made. The only analogy I can give is to compare him to a child with a new train set. He's always excited to figure out how things work and he loves talking about all of the development details, like what challenges we faced, where we made compromises, and new and interesting ways we've used to overcome obstacles.
Nice interview John! I'm looking forward to showing you what's been keeping me so busy lately.
Other articles about what we do at Visible Asests:
Converge! Network Digest [20060609]:
IEEE Begins Work on Wireless, Long-Wavelength Standard
Sensors Specialty Markets [20060612]:
New Wireless Standard for Healthcare and Livestock Visibility Networks
RF GlobalNet [20060612]:
IEEE Begins Wireless, Long-Wavelength Standard for Low-Cost Radio Tags
RF Design [20060614]:
New IEEE standard to bring local network protocol to thousands of radio tags with long battery lives
RFID Journal [20060619]:
Visible Assets Promotes RuBee(tm) Tags for Tough to Track Goods
IDTechEx [20070208]:
IEEE RuBee(tm) Network Standard Meeting
Epson [20070507]:
Visible Assets, RuBee(tm) Technology Leader, Announces Investment from Epson Electronics America
20071116
P2P Distributed Filesystem for Portage Binary Packages
After my latest post about the exponential size of a potential Gentoo / Portage database of binaries (indexed by use flags, build dependencies, etc) I just came up with a fairly interesting idea.
Who else (who we all know and love) has as much (and likely far more) data to index? Obviously, Google ;-) Googles method of indexing data is using their distributed filesystem.
So why couldn't binaries based on Portage ebuilds be indexed in such a fashion. Well, since the volume of data, indexed by use flags, build dependencies, etc, would be so massive, it's unlikely that any single, community-driven server could host such data alone.
If the community was involved, though, it wouldn't be too far fetched to make the binary-distribution distributed filesystem available on Peer-to-Peer networks. The same hashing technique could be used for each of the various packages that's being built. Furthermore, as has been pointed out by others already, the environmental impact that Portage has is probably intriguing, considering that every package installed by the average user is compiled from source.
And let's be honest with each other - the bottom line in using software is using it, and not building it.
++ for P2P networking AND Gentoo :)
Update [ 2007-11-30 ]: I also mentioned this once on Daniel Robbins' blog - Funtoo
Who else (who we all know and love) has as much (and likely far more) data to index? Obviously, Google ;-) Googles method of indexing data is using their distributed filesystem.
So why couldn't binaries based on Portage ebuilds be indexed in such a fashion. Well, since the volume of data, indexed by use flags, build dependencies, etc, would be so massive, it's unlikely that any single, community-driven server could host such data alone.
If the community was involved, though, it wouldn't be too far fetched to make the binary-distribution distributed filesystem available on Peer-to-Peer networks. The same hashing technique could be used for each of the various packages that's being built. Furthermore, as has been pointed out by others already, the environmental impact that Portage has is probably intriguing, considering that every package installed by the average user is compiled from source.
And let's be honest with each other - the bottom line in using software is using it, and not building it.
++ for P2P networking AND Gentoo :)
Update [ 2007-11-30 ]: I also mentioned this once on Daniel Robbins' blog - Funtoo
Subscribe to:
Posts (Atom)