Tiago Bortoletto Vaz: Recycling old Debian t-shirts
...and having beautiful dreams :)
...and having beautiful dreams :)
...and having beautiful dreams :)
...and having beautiful dreams :)
 |  |  |
The challenge is now more and more to find good places to run without
too much cars and noises....and not too far away.
Today, I think I made it well..:-)
After a look on the map, and some wild guess from what I now know of
the way the city is organized, I decided to go south-west of Managa,
from the hotel Seminole.
This is again a hilly run because, anyway, wherever you go south in
Managua, you're going up.
Ralf, who arrived just yesterday, joined me and, I guess, enjoyed the
run.
After going through an obviously quite rich neighbourhood with nice
villas, gardeners, huge US truck-style cars, we went close to the
Mormonschurch...and a mosque, then headed westward close to "Colegio
Americano", with fences, walls, guards in the corner, etc. Seems that
any tiny bit of USA in the world needs an army to protect it.
Crossing la Pista Suburbana, we then went on a very quiet roads
towards the hill, in a very green and peaceful area. House there were
really not as fancy as in other places, even seeming quite "poor" in
some way. However, we never felt any problem and people we meet on the
way are always friendly and smiling : "Hola", "Buenos Dias", etc.
At the end of the road, after about half an hour, we decided to head
back. However, as going back the same way is boring, I suggested we
head up west as my phone's map (it is very helpful to have a
smartphone with GPS and Google Maps for wandering through unknwon
places) was mentioning another road going north-west a little bit
westward.
So we entered a small trail between house farms...with dogs! These
were a bit "scary" as they were barking at us and of course running
entirely freely. On the other hand, none was really aggressive and we
had no problem. I however saw a few people really staring at us as I
guess there are not so many runners in this place..:-). But still, we
never felt unsafe: just in a quite uncommon place.
After abotu 500m we found the "road" that was on my map: indeed a path
going down slowly along the hill. And there was the marvel. An
incredible panoramic view going going the volcanoes that are East and
North of Leon : San Cristobal, Telica Rota, Pilas elHoj and last but
definitely not least: EL
MOMOTOMBO. A nearly perfect pyramid-style
volcano that lies about 50km north-west of Managua, on the eastern
shore of Managua Lake. The view there is...just fantastic with also a
180 panorama to West and North-West of the lake and the volcanoes area.
After this, all we had to do was heading back to the hotel and share
this with you...:-)
As usual, the
full GPS trace is here.
Correct me if I m wrong (and I really want to be wrong).mastersrv:~# lvs LV VG Attr LSize Origin Snap% Move Log Copy% Convert backup virtual -wi-ao 50,00g mainsrv virtual -wi-ao 300,00g redminbu virtual swi-a- 5,00g redmine 0,00 redmine virtual owi-a- 19,53g
mastersrv:~# lvs LV VG Attr LSize Origin Snap% Move Log Copy% Convert backup virtual -wi-ao 50,00g mainsrv virtual -wi-ao 300,00g redminbu virtual Swi-I- 5,00g redmine 100.00 redmine virtual owi-ao 19,53g
[13402279.777238] device-mapper: snapshots: Invalidating snapshot: Unable to allocate exception.
mastersrv:~# pvs PV VG Fmt Attr PSize PFree /dev/md0 virtual lvm2 a- 884,01g 514,46g
Forward Error Correction with the TI CC1120 Sub-GHz transceiver
We re building a new, fancier flight computer and decided to give the
new, fancier TI CC1120 chip a try.
It has significantly more transmit power (+16dBm) and receive
sensitivity (-109dBm) than the transciever built in to
the TI CC1111 RF SoC that we ve
built our other boards with. Given that we d already decided to use a
fancier STM32L
processor, using the nicest stand-alone radio chip we could find
seemed to make good sense.
One of the nice features found in the CC1111 is support for FEC using a
1/2 rate constraint length 4 convolutional code.
Both the encoder and the soft-decision Viterbi decoder
are built right into the chip; all we had to do was flip a couple of
bits and we got error correction, interleaving, data whitening and CRC
checking all for free.
We assumed that, as the CC1120 was advertised as a better
replacement for our CC1111 radio, that it would also include all of
these fine features. After we got the chip all soldered down to our
first prototype boards, we read through the reference manual looking
for the right register values to flip for forward error correction. We
found support for CRC computation and data whitening, but no mention
of interleaving or forward error correction at all.
Thanks, TI. Of course, without the FEC pieces, the other packet
handling hardware is worthless you can t exactly do a CRC on the
encoded data and expect it to be useful on the other end of the link,
and data whitening happens after the CRC.
Basic CC1120 driver
I assumed I d eventually figure out something to do about the FEC
pieces and started writing a basic
CC1120 driver
AltOS, the operating system used in
all of our projects. I started with the transmit side, as that seemed
easier as I could use the existing packet hardware by uploading the
desired bit sequence using whatever fancy encoding desired and the
hardware would happily transmit it.
I first tested that using low data-rate bits (2kbps), transmitting an
alternating sequence of zeros and ones to generate a 1kHz tone on a
regular 70cm receiver. That seemed to work just fine, demonstrating
that I had some grasp of the basic operation of the chip.
Convolutional Encoding in Software
Not to be daunted by a small challenge in software, I set out to
replicate the encoding scheme used in the CC1111 chips for use in our
CC1120-based design. We obviously want our CC1120 boards to
interoperate with the CC1111 boards. Fortunately, TI
fully documents
the CRC, data whitening, convolutional encoding and interleaving done
in the hardware.
I created my own implementation of the encoder (licensed, as usual, under the
GPLv2) which you can see in the file
ao_fec_tx.c
It s not quite as flexible as the hardware, it always whitens the data
and always appends the CRC bytes to the end of the packet, along with
the necessary trellis termination bytes.
The core of that code is surprisingly simple:
static const uint8_t ao_fec_encode_table[16] =
/* next 0 1 state */
0, 3, /* 000 */
1, 2, /* 001 */
3, 0, /* 010 */
2, 1, /* 011 */
3, 0, /* 100 */
2, 1, /* 101 */
0, 3, /* 110 */
1, 2 /* 111 */
;
uint8_t
ao_fec_encode(const uint8_t *in, uint8_t len, uint8_t *out)
uint8_t extra[AO_FEC_PREPARE_EXTRA];
uint8_t extra_len;
uint32_t encode, interleave;
uint8_t pair, byte, bit;
uint16_t fec = 0;
const uint8_t *whiten = ao_fec_whiten_table;
extra_len = ao_fec_prepare(in, len, extra);
for (pair = 0; pair < len + extra_len; pair += 2)
encode = 0;
for (byte = 0; byte < 2; byte++)
if (pair + byte == len)
in = extra;
fec = *in++ ^ *whiten++;
for (bit = 0; bit < 8; bit++)
encode = encode << 2 ao_fec_encode_table[fec >> 7];
fec = (fec << 1) & 0x7ff;
interleave = 0;
for (bit = 0; bit < 4 * 4; bit++)
uint8_t byte_shift = (bit & 0x3) << 3;
uint8_t bit_shift = (bit & 0xc) >> 1;
interleave = (interleave << 2) ((encode >> (byte_shift + bit_shift)) & 0x3);
*out++ = interleave >> 24;
*out++ = interleave >> 16;
*out++ = interleave >> 8;
*out++ = interleave >> 0;
return (len + extra_len) * 2;
for (state = 0; state < 8; state++)
struct ao_soft_sym zero = ao_soft_sym(ao_fec_encode_table[state * 2 + 0]);
struct ao_soft_sym one = ao_soft_sym(ao_fec_encode_table[state * 2 + 1]);
uint8_t zero_state = ao_next_state(state, 0);
uint8_t one_state = ao_next_state(state, 1);
int zero_cost = ao_cost(s, zero);
int one_cost = ao_cost(s, one);
zero_cost += cost[b][state];
one_cost += cost[b][state];
if (zero_cost < cost[b+1][zero_state])
prev[b+1][zero_state] = state;
cost[b+1][zero_state] = zero_cost;
if (one_cost < cost[b+1][one_state])
prev[b+1][one_state] = state;
cost[b+1][one_state] = one_cost;
for (state = 1; state < 8; state++)
if (cost[b][state] < c)
c = cost[b][state];
min_state = state;
for (b = len/2; b > 0; b--)
bits[b-1] = min_state & 1;
min_state = prev[b][min_state];
| History Length | Total Packets | Correct | Incorrect |
|---|---|---|---|
| 8 bits | 100000 | 90520 (90.52%) | 9480 (9.48%) |
| 24 bits | 100000 | 93614 (93.61%) | 6386 (6.39%) |
| 56 bits | 100000 | 93620 (93.62%) | 6380 (6.38%) |
/* Metric for a zero bit */
uint32_t bitcost = ((uint32_t) (s0 ^ ao_fec_decode_table[(state<<1)]) +
(uint32_t) (s1 ^ ao_fec_decode_table[(state<<1)+1]));
/* Total path metric and state for a zero bit */
uint32_t cost0 = cost[p][state] + bitcost;
uint8_t state0 = ao_next_state(state, 0);
/* Compare the total path metric against all existing
* metrics heading into the same new state, choosing
* the least expensive and killing the others. Record
* the new lowest cost and output bit.
*/
if (cost0 < cost[n][state0])
cost[n][state0] = cost0;
bits[n][state0] = (bits[p][state] << 1) (state & 1);
/* Total path metric and state for a one bit. Because
* encoding a one is always exactly the opposite of
* encoding a zero from any state, this cost is
* 255*2 - bitcost
*/
uint32_t cost1 = cost[p][state] + 510 - bitcost;
uint8_t state1 = ao_next_state(state, 1);
if (cost1 < cost[n][state1])
cost[n][state1] = cost1;
bits[n][state1] = (bits[p][state] << 1) (state & 1);
/* Metric for a zero bit */
bitcost = ((uint32_t) (s0 ^ ao_fec_decode_table[(state<<1)]) +
(uint32_t) (s1 ^ ao_fec_decode_table[(state<<1) 1]));
/* Only state and state+4 reach state<<1 with a zero bit */
/* Cost from state to state<<1 for a zero bit*/
m0 = cost[p][state] + bitcost;
/* Cost from state+4 to state<<1 for a zero bit */
m1 = cost[p][state+4] + (510 - bitcost);
/* Which source state is cheaper? */
bit = m0 > m1;
/* Record the cheaper cost and the add to the path of bits */
cost[n][state<<1] = bit ? m1 : m0;
bits[n][state<<1] = (bits[p][state + (bit<<2)] << 1) (state&1);
/* State and state+4 reach (state<<1)+1 with a one bit */
/* Cost from state to (state<<1)+1 for a one bit */
m0 -= (bitcost+bitcost-510);
/* Cost from state+4 to (state<<1)+1 for a one bit */
m1 += (bitcost+bitcost-510);
/* Which source state is cheaper? */
bit = m0 > m1;
/* Record cheaper cost and add to the path of bits */
cost[n][(state<<1)+1] = bit ? m1 : m0;
bits[n][(state<<1)+1] = (bits[p][state + (bit<<2)] << 1) (state&1);
I'm here in managua since sunday evening, & by now DebCamp is slowly
getting to its end. So here are some of my impressions so far:
Yet another Grand Plan today: run in Masaya Volcan National Park.
Masaya
Volcano is one of the most active volcanoes in Nicaragua. It is
located only 20km south-east of Managua, so going there is as easy as
renting a taxi.
The original plan was to drive to the entrance of the National park
(on the road to Masaya city), then run up to the volcan, so from 250m
altitude up to about 600m.
I therefore rented a taxi with the kind help of Norman, and we agreed
to meet up at 08:30 at the hotel, along with No l and Daniel (who was
planning to walk up, not running).
After discussing here or there, Kurt and Gaudenz joined, both with the
intent of running up. Others would also have liked to join, but I
wasn't in the mood of organizing a full bus of Debconfers..:-). My
plan was to enjoy pyself the hike...not to manage several taxis, etc.
We thus packed in Denis blue taxi...a fancy and very visible
customized blue car that looked like it had been the topic of on
episode of the "Pimp My Ride" TV show..:-)
Sitting 4 people at the back of a regular car without hitting some
blue neon lights, or 7" TV screens is kinda tricky, but we made it.
When arriving at the park's entrance, we however learned that it is
forbidden to walk or hike up the road by foot, because of potential
high concentrations of Carbon Dioxide. Sadly, we then had to pack
again in the car and go up with it.
After reaching the parking close to the volcano's active crater
(that is said to have a small lava lake at its bottom, one of the very
few in the world), we decided to head up for going round the Nindira
crater, an inactive crater located slightly above. Unfortunately,
again, the path around the Masaya crater is forbidden to walk on,
because of landslides.
We indeed still had great fun by running around this crater (which is
about a 2.5 kilometers round trip, very very hilly and sometimes hard
to run on such as a mountain path.
After about 50 minutes and two laps (after all, we had a giant
stadium!), we headed back to the parking, packed 5 sweating geeks in
the car and went back to the hotel.
Full GPS trace is
here. I also put a few pictures on Facebook, supposedly visible by
anybody : Masaya
crater and Nindiri
crater.
[...] read also says how many bytes of the file were returned, so end of file is assumed when a read says "zero bytes are being returned." [...] When a program reads from your terminal, each input line is given to the program by the kernel only when you type its newline (i.e, press RETURN). [...] [...] Now try something different: type some characters and then a *ctl*-d rather than a RETURN: $ cat -uBrian W. Kernighan, Rob Pike. The UNIX Programming Environment. Prentice-Haskell Software Series, 1984, section 2.1, pages 44-45.
123ctl-d123 cat prints the characters out immediately. *ctl*-d says, "immediately send the characters I have typed to the program that is reading from my terminal." The *ctl*-d itself is not sent to the program, unlike a newline. Now type a second ctl-d, with no other chracters: $ cat -u
123ctl-d123ctl-d$ The shell responds with a prompt, because cat read no characters, decided that meant end of file, and stopped. ctl-d sends whatever you have typed to the program that is reading from the terminal. If you haven't typed anything, the program will therefore read no characters, and that looks like the end of the file. That is why *ctl*-d logs you out --- the shell sees no more input. Of course, *ctl*-d is usually used to signal an end-of-file but it is interesting that is has a more general function.
Most x86 devices export various bits of system information via SMBIOS, including the system manufacturer, model and firmware version. This makes it possible for the kernel to alter its behaviour depending on the machine it's running on, usually referred to as "DMI quirking". This is a very attractive approach to handling machine-specific bugs - unfortunately it also means that we often end up working around symptoms with no understanding of the underlying issue.gobby.debian.org. I've just amended
the howto to point to that, and updated the info about which gobby
package to use (nowadays clarified, thanks to
Phil).
Enjoy your BoF-s!
It's still good to be at Debcamp before DebConf and I'm not running
all day long, contrary to what you might think by reading my posts.
Of course, I'm always busy with "social-like" activities such as doing
my best for us to have a good Cheese and
Wine Party as, now that I'm
trapped into it, people expect it to be better and better each year.
Or to revive the traditional Assassins
game.
But Debian is not only about killing cheese with socks and I try to
also achieve a few things while being here.
As of now, I can already count a few things:
Hello, Internets!
After a bit of a disappointment with Lenovo, they ve come through with flying colors, My 520i s palmrest fractured in a couple of really gnarly ways. The machine was still usable, but the fractures were really bad, looked really gnarly and creaked a bit when I put any pressure around it.
After having fancyhands call them a few times, each time returning a different part number, I complained on twitter only tagging @lenovo as an afterthought which (to my surprise) got a fast response and helpful email service.
Here I am, 3 days later with a replaced palmrest. Nice ending, but I hope it won t happen again :)
Yay, got to Nicaragua OK last night. It's the first time I've
managed to get to DebCamp in quite a while, and I'm making the most of
it. I've got slides ready for two of my BoF sessions next week (both
ARM-related), and I'm preparing for the other four now. Why did I sign
up to run six sessions? Maybe because I'm a bit silly, or maybe
because they needed doing and other people hadn't registered
them. Maybe both. :-)
BTW: these are all BoF (Birds of a Feather) sessions, not
lectures. While I have an interest in each topic, I'm neither wanting
nor expecting to just talk at a room full of people -
I'm wanting to provoke discussions in each case. If you're interested,
please join in those discussions, either physically in Managua or
virtually using
the live video
streaming and IRC back-channels:
See you there...!
I reached a nice milestone on my
git-annex assistant
in my first day's work at DebCamp in Nicaragua. Here's a screencast
demoing it.
<video controls="controls" src="http://joeyh.name/screencasts/git-annex-assistant.ogg"></video>
git-annex-assistant.ogg (12 MB)
By the way, the weather, food, and people here are all excellent.
Many community driven projects have a problem with overgrown
bureaucratic processes reducing the desire and ability of casual
contributors to contribute. Debian has struggled with this problem,
with efforts like Debian Maintainers and sponsorship to address it,
but it's insidious and difficult to completely overcome. I recently
ran into this problem again with Wikipedia, where I'm a casual
contributor (I probably average an edit a month).
Sometime in 2006, I uploaded an image of a Boojum tree I took in 2004
to Wikipedia to provide an image for the
Boojum tree article. It
wasn't a particularly awe inspiring image, as I took it while I was
teaching second quarter freshmen biology on campus, and showing the
students the awesome
Botanical Gardens at UCR. In 2011, a
Wikipedia user asked for deletion of the image because of some
confusion about the copyright on the image, as
Apache::Gallery's default template footer
contains Apache::Gallery's copyright. I didn't notice that during the
7 day deletion review period because I rarely log into Wikipedia.
A few days ago, I noticed the deletion and asked for a
Deletion Review.
I assumed that my explanation that the copyright notice was for
Apache::Gallery would be understood (or at least believed), and that
at least the original reason for the deletion would be seen to be
invalid. Instead, during
the process
I was questioned as to whether I actually took the picture, why I used
GPLv2+ for the pictures, whether I was claiming other people's images,
and whether the image was actually good enough to be in Wikipedia in
the first place. Hundreds of lines of text, an edit to the template in
A::G, hours wasted, people still unsatisfied, and the potential
contributor (myself) feeling so annoyed with the entire process that I
bothered to write this blog entry.
While I'm not sure what to do about Wikipedia, I've been forcibly
reminded of how important enabling easy contributions are, and how
alienated one can feel when one is stymied by them to the point that
your (admittedly insignificant) contribution to a project no longer
seems worth the effort.
The Grand Plan today was reaching the end of the road I already
explored on Tuesday. Named "Camino Las
Viudas", it's climbing in the southern hills up to a place named
"Intermzeeo del Bosque", apparently a very fancy (and expensive)
restaurant.
The road climbs in the apparently "rich" neighbourhood of Managua,
with very fancy villas as guarded by private security, as well as
private condominiums, guarded as well.
What's funny to see is that, at the bottom of the road, when it
crosses a large avenue (Pista Suburbana Espana), you can find several
auto-rickshaws,
just like those you find everywhere in India.
Those autos
apparently drive people who happen to work in these villas (like
maids, gardeners, security guards, etc.) up to the place they work.
We even met two cows wandering on the road and I hesitated waiting for
a rickshaw to show up and take a pic of the road (with holes), the
auto and the cows, then pretending that I'm no longer in Nicaragua but
back
in Karnataka.
I did the run along with No l K the, who I was very happy to find
again, restoring our now famous Debconf Runners Duet. We even found the
German Embassy!
Though climb, even if we took care to start at 6 a.m. to avoid the
heat (and also the traffic and noise). No l unfortunately had to give
up at 1km from the top of the road, when a 15% climb suddenly "killed"
his legs. I need to train him more for ups and downs..:-)
I could continue the road and finally reached the restaurant....which
was guarded by private security (as apparently everything in this
country) who unfortunately didn't let me in despite my desperate
attempts to convince him, in broken Spanish, that I just wanted to
take a few pictures and not place a bomb or rob someone...
So, I gota little bit disappointed and the only option was then....to
run down for another 8.5 kilometers, accelerating all the way, to finish
nearly at 14 km/h on Managua's sidewalks...Fun.
Great run (nearly 400m positive slope in less than 17km). Next
challenge : find another such nice run in the neighbourhood! Maybe
Volcan Masaya tomorrow.
GPS trace is here.
As Weblate 1.1 is out, it's time to schedule next release. This release will bring some small improvements to the workflow, especially it will allow to tune it to different use cases than I originally had in mind.
I've already started tagging bugs and feature requests to be fixed in 1.2 in [issue tracker][4]. Basically no big features on the list, just smaller things like notifications and locking. And of course dozen of bugfixes as the bugs will appear :-).
As you can see there as well, 1.2 should be ready about month from now. This will be possible only thanks to Hackweek VIII (the wiki is still showing last one), which will happen from July 23rd to July 27th. The rest is time for testing the features and polishing the features.
Anyway I might have time for some other features as well, so 1.2 might bring more things than I currently plan. But that depends on how fast I will be in implementing planned stuff.
Filed under: English Suse Weblate 0 comments Flattr this!
Next.
