Fountains of Paradise

23.11.2012 22:15

On my recent trip to Trinity College Dublin, I've spent almost two full days at airports and on airplanes. I did have a loaded Kindle with me, so during that time I had the opportunity to finish The Fountains of Paradise by Arthur C. Clarke which I started reading a few day earlier.

I'm pretty much a fan of his science fiction works and have most of them on my bookshelf in paperback form. Fountains of Paradise however is one novel I haven't yet read. In a somewhat fragmented way it follows the construction of a space elevator and its chief engineer. The space elevator idea actually appears quite often in Clarke's stories (for instance in Songs of the distant Earth, or 3001). I guess that's not surprising, considering the concept is related to the geostationary orbit, something Clarke has professionally worked on. But there it's mostly just a part of the scenery. Here though, the elevator's construction is the focus of the story, as are the philosophical questions and engineering and social challenges it raises.

Main characters in the novel are portrayed in much the same way as I remember from most other Clarke's stories I read. They are always most rational thinkers, very devoted to their profession and fully in control of their minds. Even when they are overcome with emotions or do something that might appear irrational for an external observer, there's always a detached, internally rational view of their behavior. Some may say that this makes them unrealistic, but I think it fits with the general futuristic theme. As a tower to the geostationary orbit might be something that bridge builders of the future might professionally strive for, such rationality can on the other hand be something people might wish to achieve personally.

Talking about towers to the stars, Clarke's vivid descriptions of natural phenomena and feats of fictional engineering are amazing and Fountains of Paradise is no exception in that regard. Some of them literally gave me goosebumps and they definitely show that contrary to the popular opinion, the world seen through the technically correct eyes of an engineer doesn't need to be dull.

Definitely worth a read if you are into this sort of thing.

Posted by Tomaž | Categories: Life | Comments »

GNU linker and ELF program header

14.11.2012 12:15

Here's a little annoyance I've been trying to fix.

Most of the time we are using a custom bootloader on VESNA. On the VESNA's STM32F1 microcontroller the flash ROM starts at the address 0x8000000 and the bootloader takes the first 0x12800 bytes of it. At CPU reset the bootloader does some housekeeping tasks, possibly reprogramming some sections of the flash ROM, and then transfers control to the application code that lives above 0x8012800.

When linking application code using GNU linker, we are using the following script:

	rom (rx) : ORIGIN = 0x08012800, LENGTH = 512K - 0x12800
	ram (rwx) : ORIGIN = 0x20000000, LENGTH = 64K

INCLUDE libopencm3_stm32f1.ld

This produces a working binary (using objdump -Obinary) when it's loaded at 0x8012800 by our bootloader.

However, sometimes it's convenient to skip the application reprogramming through the bootloader (which is slow for unrelated reasons) and program the application code directly through JTAG using openocd. Strangely enough this corrupts the bootloader, even though the linker MEMORY definition above only specifies the application area of the ROM.

Looking closely at the ELF file produced by the linker, I noticed the program headers:

Program Header:
0x70000001 off    0x0000e4cc vaddr 0x0801e4cc paddr 0x0801e4cc align 2**2
         filesz 0x000000e8 memsz 0x000000e8 flags r--
    LOAD off    0x00000000 vaddr 0x08010000 paddr 0x08010000 align 2**15
         filesz 0x0000e5b4 memsz 0x0000e5b4 flags r-x
    LOAD off    0x00010000 vaddr 0x20000000 paddr 0x0801e5b8 align 2**15
         filesz 0x000009b4 memsz 0x00000bc0 flags rw-
private flags = 5000002: [Version5 EABI] [has entry point]

For some reason GNU linker insists on aligning program segments on a 32 kB boundary. Therefore it aligns the segment containing the application code at 0x8010000, which is 0x2800 bytes inside the bootloader territory. Since the code still has to start at 0x8012800, it pads the start of the segment and this padding overwrites a part of the bootloader when it's loaded into flash ROM by openocd.

Why does it do that? I have no idea. There also doesn't seem to be any option to adjust the alignment (flash ROM in this microcontroller has 512 byte pages, so it would make more sense to align the segments to those).

The simplest solution I've found is to simply dump the plain binary with objdump and use that instead of the ELF file with openocd. But that's ugly, because then you have to repeat the segment offset in the openocd script.

Posted by Tomaž | Categories: Code | Comments »

Deteriorating radios

09.11.2012 17:13

If you've been following my writings (or if you've been at my recent talk in Kiberpipa) you probably remember that the department of Institute Jožef Stefan I work for has built an out-door test bed for cognitive radio experiments. In practice this means 50 or so VESNA boards with my experimental spectrum sensing radio hardware mounted in weather-proof plastic boxes on public light poles.

Since June, when the first batch of VESNAs were mounted, something curious has happened with the radio hardware. 2.4 GHz transceivers based on the Texas Instruments CC2500 integrated circuit degraded significantly on receiver sensitivity and transmit power. In some cases to such a degree that they became practically useless for any research work. In fact, this was discovered when we could not explain experimental results we were getting from some of VESNA nodes and started doubting that our equipment is functioning properly.

A pile of SNE-ISMTV boards and pigtail cables.

Since this hardware has been exposed for several months to daily temperature and humidity variations (boxes aren't airtight) and the antennas are mounted externally, my first guess was that perhaps the antenna connector oxidized or the coaxial cable deteriorated.

Here's a plot of receiver sensitivity and maximum transmitter power variations for a sample of VESNA nodes. First five from the left have been mounted out-doors in the test bed, while the other six have been deployed in-doors in the Institute. All printed circuit boards are from the same batch, and hence have exactly the same hardware and approximately the same number of operating hours. 0 dB here means nominal sensitivity and transmit power.

Receive sensitivity and transmit power offsets for SNE-ISMTV-2400 boards

It's quite obvious that nodes from outside have a significantly larger deviation from typical values. What's interesting is that transmit power and receiver sensitivity didn't change consistently, which as far as I can see contradicts the theory that this is due to some simple attenuation on the path between the transceiver IC and the antenna.

In fact, you have to replace both the circuit board and the short coaxial cable to the antenna to restore the original characteristics. This can only mean that both of these are responsible for the problem. Regarding the transceiver, I can't think of any environmental effect that would deteriorate a silicon chip inside a sealed plastic package in this way. I think more likely suspects are the balun circuit and the few other external passive components that might have absorbed moisture or got affected by temperature variations.

Posted by Tomaž | Categories: Analog | Comments »

Remote Wireshark recipe

05.11.2012 17:03

Recently I've been trying to debug some SSL connection problems on remote machines. While tcpdump in an console-only ssh sesion usually does the trick for me, this time I really needed the user-friendliness of filters and SSL decryption features in Wireshark. I really didn't want to install Wireshark on a head-less server and do X11 forwarding, so I used tcpdump to do the actual capture on the server and forwarded the stream through a pipe and an ssh connection to Wireshark on my laptop.

Here's the recipe, mostly for my record and in case someone else might find it useful. I had problems with other recipes I found, since they either use dumpcap, which I don't have on the remote, or make it hard to start the packet capture command through sudo.

On remote machine:

$ mkfifo foo
$ sudo tcpdump not port 22 -U -w - >foo

(just pointing -w to a pipe won't work)

On the local machine:

$ wireshark -k -i <(ssh cat foo)
Posted by Tomaž | Categories: Code | Comments »

HMS Belfast

01.11.2012 19:12

On my recent trip to London I also visited HMS Belfast. I've seen her a few times before from the outside and I remember extensive coverage of this floating museum in one of our popular science magazines several years ago, but until now I never found the time to actually go on board.

Random collection of gages in the engine room of HMS Belfast

The ship is well worth a visit, even if you're not particularly interested in military technology. Although in terms of electrical engineering there's not much to see. Most of the original electronics equipment is gone, supposedly because it was still secret when the ship was decommissioned and opened to public. You can see some racks with radios from afar (with added random sparks, for theatrical effect) and a workplace for a group of veteran HAM operators that still answer the original ship call sign. Original CRT radar displays have been replaced with a surprisingly authentic-looking mechanical simulations using rotating semi-transparent screens.

The engine rooms however more than make up for that. If you're into steam turbines, big brass gages, huge transmissions and other such things, of course. Compared to rooms housing electrical equipment where you have to stay behind fences and closed doors, here you can actually look at the control panels in detail. It's interesting to pause in the cramped spaces between various conduits and try to figure out what is the purpose of this or that instrument.

Admiralty Fire Control Table on HMS Belfast

Above, by the way, is a mechanical analogue computer for calculating ballistic trajectories called Admiralty Fire Control Table.

One other interesting thing I noticed during my stroll around the ship was a distinct lack of chairs for the crew. Except for the rooms where the crew slept and ate, almost all work positions seemed to require standing, as also demonstrated by occasional mannequins in the exhibition. That rang a bell since it's a standing joke about Star Trek that it features futuristic space ships that lack chairs and seat belts. I wonder what the rationale behind their absence was in the case of this quite real battleship. After reading recollections of various battles that were on display in the museum I had the impression that being thrown into the nearest bulkhead was a quite real possibility.

Posted by Tomaž | Categories: Life | Comments »