Planet Linux Australia

Syndicate content
Planet Linux Australia -
Updated: 1 hour 18 min ago

Tridge on UAVs: APM:Plane 3.2.2 released

Tue, 2015-02-10 09:20
The Ardupilot development team has released version 3.2.2 of APM:Plane. This is a bugfix release for some important bugs found by users of the 3.2.1 release.

The changes in this release are:

  • fixed a bug that could cause short term loss of RC control with some receiver systems and configurations
  • allowed for shorter sync pulse widths for PPM-SUM receivers on APM1 and APM2
  • fixed HIL mode altitude
The most important bug fix is the one for short term loss of RC control. This is a very long standing bug which didn't have a noticeable impact for most people, but could cause loss of RC control for around 1 or 2 seconds for some people in certain circumstances.

The bug was in the the AP_HAL RCInput API. Each HAL backend has a flag that says whether there is a new RC input frame available. That flag was cleared by the read() method (typically hal.rcin->read()). Callers

would check for new input by checking the boolean hal.rcin->new_input() function.

The problem was that read() was called from multiple places. Normally this is fine as reads from other than the main radio input loop happen before the other reads, but if the timing of the new radio frame

exactly matched the loop frequency then a read from another place could clear the new_input flag and we would not see the new RC input frame. If that happened enough times we would go into a short term RC

failsafe and ignore RC inputs, even in manual mode.

The fix was very simple - it is the new_input() function itself that should clear the flag, not read().

Many thanks to MarkM for helping us track down this bug by providing us with sufficient detail on how to reproduce it. In Marks case his OpenLRSng configuration happened to produce exactly the worst case timing needed to reproduce the issue. Once I copied his OpenLRS settings to my TX/RX I was able to reproduce the problem and it was easy to find and fix.

A number of users have reported occasional glitches in manual control where servos pause for short periods in past releases. It is likely that some of those issues were caused by this bug. The dev team would like to apologize for taking so long to track down this bug!

The other main change was also related to RC input. Some receivers use a PPM-SUM sync pulse width shorter than what the APM1/APM2 code was setup to handle. The OpenLRSng default sync pulse width is 3000 microseconds, but the APM1/APM2 code was written for a minimum sync pulse width of 4000 microseconds. For this release I have changed the APM1/APM2 driver to accept a sync pulse width down to 2700 microseconds. This release also fixes HIL mode altitude. I am hoping this will be the last release where you need to have a separate firmware for HIL mode and normal flight mode. In the future we will have a HIL_MODE parameter, and if that is set at boot then the board will run in HIL mode. That will make it easier to run HIL on all boards (eg. Pixhawk, NavIO, Erle etc) without having to recompile and reload firmware. Happy flying!

Ian Wienand: Netgear CG3100D-2 investigation

Mon, 2015-02-09 04:52

The Netgear CG3100D-2 is the default cable-modem you get for Telstra Cable, at least at one time. Having retired it after changing service providers, I wanted to see if it was somewhat able to be re-purposed.

In short it's hackability is low.

First thing was to check out the Netgear Open Source page to see if the source had anything interesting. There is some source, but honestly when you dig into the platform code and see things like kernel/linux/arch/mips/bcm963xx/setup.c:

/*************************************************************************** * C++ New and delete operator functions ***************************************************************************/ /* void *operator new(unsigned int sz) */ void *_Znwj(unsigned int sz) { return( kmalloc(sz, GFP_KERNEL) ); } /* void *operator new[](unsigned int sz)*/ void *_Znaj(unsigned int sz) { return( kmalloc(sz, GFP_KERNEL) ); } ...

there's a bit of a red-flag that this is not the cleanest code in the world (I guess it interfaces with some sort of cross-platform SDK written in some sort of C++).

So next we can open it up, where it turns out there are two separate UARTs as shown in the following image.

One of these is for the bootloader and eCOS environment, and the other seems to be connected to the Linux side.

A copy of the boot-logs for the bootloader and eCOS and Linux don't show anything particuarly interesting. The Linux boot does identify itself as Linux version 2.6.30-V2.06.05u while the available source lists its version as 2.6.30- so it's questionable if the source matches whatever firmware has made it onto the modem.

We do see that this identifies as a BCM338332 which seems to be one of the many sub-models of the BCM3383 SoC cable-modem solution. There is an OpenWrt wiki page that indicates support is limited.

Both Linux and eCos boot to a login prompt where all the usual default combinations of login/passwords fail. So my next thought was to try and get to the firmware via the bootloader, which has a simple interface

BCM338332 TP0 346890 Reset Switch - Low GPIO-18 50ms MemSize: 128 M Chip ID: BCM3383G-B0 BootLoader Version: 2.4.0alpha14R6T Pre-release Gnu spiboot dual-flash reduced DDR drive linux Build Date: Mar 24 2012 Build Time: 14:04:50 SPI flash ID 0x012018, size 16MB, block size 64KB, write buffer 256, flags 0x0 Dual flash detected. Size is 32MB. parameter offset is 49944 Signature/PID: a0e8 Image 1 Program Header: Signature: a0e8 Control: 0005 Major Rev: 0003 Minor Rev: 0000 Build Time: 2013/4/18 04:01:11 Z File Length: 3098751 bytes Load Address: 80004000 Filename: CG3100D_2BPAUS_V2.06.02u_130418.bin HCS: 1e83 CRC: b95f4172 Found image 1 at offset 20000 Image 2 Program Header: Signature: a0e8 Control: 0005 Major Rev: 0003 Minor Rev: 0000 Build Time: 2013/10/17 02:33:29 Z File Length: 3098198 bytes Load Address: 80004000 Filename: CG3100D_2BPAUS_V2.06.05u_131017.bin HCS: 2277 CRC: a6c0fd23 Found image 2 at offset 800000 Image 3 Program Header: Signature: a0e8 Control: 0105 Major Rev: 0002 Minor Rev: 0017 Build Time: 2013/10/17 02:22:30 Z File Length: 8277924 bytes Load Address: 84010000 Filename: CG3100D_2BPAUS_K2630V2.06.05u_131017.bin HCS: 157e CRC: 57bb0175 Found image 3 at offset 1000000 Enter '1', '2', or 'p' within 2 seconds or take default... . . Board IP Address []: Board IP Mask []: Board IP Gateway []: Board MAC Address [00:10:18:ff:ff:ff]: Internal/External phy? (e/i/a)[a] Switch detected: 53125 ProbePhy: Found PHY 0, MDIO on MAC 0, data on MAC 0 Using GMAC0, phy 0 Enet link up: 1G full Main Menu: ========== b) Boot from flash g) Download and run from RAM d) Download and save to flash e) Erase flash sector m) Set mode s) Store bootloader parameters to flash i) Re-init ethernet p) Print flash partition map r) Read memory w) Write memory j) Jump to arbitrary address X) Erase all of flash except the bootloader z) Reset Flash Partition information: Name Size Offset ===================================== bootloader 0x00010000 0x00000000 image1 0x007d0000 0x00020000 image2 0x007c0000 0x00800000 linux 0x00800000 0x01000000 linuxapps 0x00600000 0x01800000 permnv 0x00010000 0x00010000 dhtml 0x00200000 0x01e00000 dynnv 0x00040000 0x00fc0000 vennv 0x00010000 0x007f0000

The "read memory" seems to give you one byte at a time and I'm not certain it actually works. So I think the next step is solder some leads to dump out the firmware from the flash-chip directly, which is on the underside of the board. At that point, I imagine the passwords would be easily found in the image and you might then be able to leverage this into some sort of further hackability.

If you want a challenge and have a lot of time on your hands, this might be your platform — but practically I think the best place for this is the recycling bin.

Sridhar Dhanapalan: Twitter posts: 2015-02-02 to 2015-02-08

Mon, 2015-02-09 00:27

Michael Still: Tuggeranong Stone Wall

Sun, 2015-02-08 20:28
Its not every day that your walk is to a 140 year old stone wall that you've been driving past for years without even knowing its there. That however was today's walk, inspired by a walk post by John Evans. I really enjoyed this walk, and it was a good length too. It would have been nice to return by a different route though, although such a thing was not obvious to me while doing the walk.


Interactive map for this route.

Tags for this post: blog pictures 20150208-tugg_stone_wall photo canberra tuggeranong bushwalk

Related posts: Big Monks; Geocaching; Confessions of a middle aged orienteering marker; Point Hut Cross to Pine Island; A walk around Mount Stranger; Another lunch time walk


Michael Still: Point Hut Crossing to Pine Island

Sun, 2015-02-08 08:29
Andrew and I decided to walk from Point Hut Crossing (near our house) to Pine Island yesterday. Its a nice walk, about 4km and mostly flat with a track the whole way. We even found some geocaches along the way. I think this route would be a good one for cubs.


Interactive map for this route.

Tags for this post: blog pictures 20150207-point_hut_pine_island photo canberra tuggeranong bushwalk

Related posts: Big Monks; Geocaching; Confessions of a middle aged orienteering marker; A walk around Mount Stranger; Another lunch time walk; Forster trig


Chris Smart: Korora 21 available

Sat, 2015-02-07 22:30

It has taken a few weeks longer than we had hoped, but Korora 21 images are now available. I strongly recommend downloading with BitTorrent if you can.

The 21 beta was quite successful and we were able to make some minor changes to help improve the overall experience. Users who are currently on the beta need not re-install, updates are provided via the package manager. Users who are on 20 may consider upgrading, however this is not necessary as version 20 is supported for another 6 months or so.

Stewart Smith: MySQL-next = Drizzle 5 years ago?

Sat, 2015-02-07 11:26

With JSON functionality, alternate protocols (HTTP, memcache), a move towards saner defaults and crash safety, pluggable logging etc it really looks like MySQL is following what we did in Drizzle years ago, which is great!

Andrew McDonnell: hacksa2015

Fri, 2015-02-06 23:27

In the middle of last year I attended Unleashed/Govhack 2014, I blogged about it here.

Barely over a week ago by pure chance I stumbled across another hackathon, this time being hacksa. This was an Adelaide only event that was designed to tie in with Entrepreneurs Week here. It seemed like an excellent opportunity to practice for the next GovHack (and a chance to meet some new people) so I entered a team! Also, I discovered that one of the people running the event was a friend of mine from uni over from Sydney for the event, so it was a good chance to catch up.

Hacksa was also going to be a small event, being first time, held at short notice, in one city, and also more focused to a specific domain (music industry) compared to GovHack. So I figured that if I managed to put into practice some of what I think I learned at Unleashed in 2014 we might stand a chance of earning some conference tickets (one of the prizes is entry to a conference called NetWorkPlay) or maybe if lucky enough cash!

Having entered a team, I had to find some teammates. So I press-ganged Mr 13, and then convinced a friend from who was in another team at Unleashed, and another friend of mine who knows a bit about business, to join in, and we set to work.

Spread Out in Time

Unlike GovHack, hacksa released the API (well, some of them) the Friday before the event. So we had the weekend to work on it. Actually we only had the weekend because the hacksa event proper was strangely held on a Wednesday, and we all had work or school.  But this was OK, we only had to show up in the evening to finalise things and do the video interview. This was another difference (and I think improvement), we didn’t have to shoot our own video.

Actually we really only had Sunday, because of life and stuff, so I put in a late one on the Saturday evening pulling together a VPS and web infrastructure for our entry, along with libraries (I decided to use twitter bootstrap to get moving in  hurry, along with Python  I’d had two ideas, one for a visualusation/infographic and the other a web app, and learning from Unleashed I intentionally stopped thinking too hard at that point and went with the web app, which was to be a mash up based initially on the V-channel chart APIs. Ultimately I think going for a web app will prove to be a good idea, we’ll see in due course.

On the Sunday we congregated at a local library and polished off the prototype. Mr 13 put together a snazzy landing page for us using weebly, and a request page using launch rock. Its pretty handy being able to divvy out tasks and keep in involved and motivated!


The hackathon event was held at a place called St Pauls Creative Center in the CBD.  It was actually a pretty nice venue for this event. We got there about 6pm which gave us a couple more hours to refine Sundays efforts and then do the video interview. Of course we got pizza which was good too because Mr 13 was pretty hungry by then :-)

Overall it felt good to actually pull something together that was essentially a working ‘minimal viable product’ (in the parlance), and we also had a good ‘story’ to tell, thanks to my friends.

I’ll probably blog more about the app itself and the API feeds a bit later.

Even if we don’t win anything, I think I’ll finish it off and we’ll go live as an experiment to see if anyone actually uses it and maybe make enough to pay for the VPS hosting for a few cups of coffee from google ads!


Andrew McDonnell: 2015 : working backwards from the end… and things that go bang!

Fri, 2015-02-06 22:26

Some of the most awesome things about LCA are events that are not part of the official programme.  These include the affectionately named BOFs, and also various things happening before and after the conference proper.

On the Saturday just after the conference, I was lucky enough that I had sufficient time before my flight home to be able to tag along to a hobbyist rocket launch meet, and watch the friendly locals, as well as the well known to the open source community rocket enthusiasts Bdale Garbee and Keith Packard, send a variety of projectiles high up into the sky! I jumped at the chance to go because my son who is 13 did a launch of a small rocket through scouts, so I thought I’d better get some pictures and video for him :-)

The next shot gives an idea of the scale of an assembled rocket:

rocket scale by Andrew Mc on 500px

The rockets launch from the middle of a paddock.

distance away by Andrew Mc on 500px

The rocketry club is really into safety, for obvious reasons. They have to get licenses to be allowed to launch, and there is a ritual each time a rocket is launched – yelling out “Sky Is Clear”, “Range Is Clear” before a launch can proceed.

This video I shot is of a small rocket launching.

One of the other’ers Augur posted some other vides to YouTube:

Watching things go bang is always fun, but these guys take it to a whole new level. If you listen carefully to the video a few minutes after the launch, notice the Android phone and the laptop actually speak the telemetry data…

This works roughly as follows: there is a computer built on Altus Metrum components in the rocket, this sends position and other data back to a receiver connected to an antenna that the flyer (is that the right word?) is holding and pointing in the general direction of the rocket… the data is then relayed via bluetooth to the phone or laptop and reported via speech synthesis. “Range one thousand two hundred seventy metres. Bearing thirty degrees south west elevation forty two degrees.”

I believe one of the rockets made it over eight kilometers high (I didn’t manage to record the exact amount!)

Eventually they run out of puff and start falling back. A parachute then deploys bringing it to ground, and a couple of km hike ensues.

I believe the following rocket is known as the Pink Freak. My daughter loved the shoes when I showed her the pics…

thepinkfreak by Andrew Mc on 500px

Alongside everything else, there was a quadcopter. When I first arrived, this was keeping a couple of the younger kids amused. But once the meet started moving, I realised it had a HD camera, and was used to monitor the rocket launches – and the pilot (this must be the right word!) had a VR headset, not an Occulus, but a new one I had not heard of, a SkyZone(?), to fly the thing way up and record the launch! It sounds like a mosquito in the videos.

I had a lot of other photos and video but many had people and I haven’t managed to make contact with the club to check if it is OK to post them, so for now I haven’t.

Michael Still: Two trigs and a first attempt at finding Westlake

Fri, 2015-02-06 08:28
I have to do HR paperwork for work at the moment, so I was looking for a quiet place to progress such things. I ended up beside Lake Burley Griffin working away on my laptop, which was quite pleasant. While in the area, it seemed like a good idea to have a quick first attempt at finding Westlake, which is the ruins of an abandoned builders camp from when Canberra was being constructed. I found some evidence, but I think I need to go further west in a subsequent wander.


Interactive map for this route.

There was a planned walk to Davidson trig by the Facebook trig sweating group this evening, so I went along to that. Beforehand I was killing time in Yarralumla and bumped into the cub leader for my kids' troop. She's interested in trig walks suitable for cubs, so I am going to have to keep an eye out for some. Davidson was a nice on-track walk, probably suitable for cubs.


Interactive map for this route.

Davidson finished about an hour earlier than expected, so I dropped in to walk to Mike on the way home in an entirely unplanned manner. This walk would be perfect for cubs if it wasn't almost entirely bush bashing. This is probably the lowest elevation trig I've been to so far.


Interactive map for this route.

Tags for this post: blog pictures 20150205-westlake_davidson_and_mike photo canberra tuggeranong bushwalk trig_point

Related posts: Big Monks; A walk around Mount Stranger; Forster trig; Taylor Trig; Oakey trig; Urambi Trig


Tridge on UAVs: APM:Plane 3.2.1 released

Thu, 2015-02-05 20:28

The ardupilot development team is proud to announce the release of version 3.2.1 of APM:Plane. This is primarily intended as a bugfix release, but does have some new features.

The major changes in this release are:

  • fixed a mission handling bug that could cause a crash if jump commands form an infinite loop (thanks to Dellarb for reporting this bug)
  • improved support for in-kernel SPI handling on Linux (thanks to John Williams)
  • support UAVCAN based ESCs and GPS modules on Pixhawk (thanks to Pavel, Holger and and PX4 dev team)
  • Multiple updates for the NavIO+ cape on RaspberryPi (thanks to Emlid)
  • multiple automatic landing fixes, including improvements in flare detection, glide slope calculation and lag handling
  • fixed a bug that could cause a change altitude MAVLink command from causing a sudden descent
  • re-enable CLI on non-APM1/APM2 boards
  • Lots of EKF changes, including reducing impact of ground magnetic interference, reducing the impact of a GPS outage and integrating optical flow support
  • added initial support for the PX4 optical flow sensor. Just logging for this release.
  • added support for MAVLink packet routing
  • added detection and recovery from faulty gyro and accel sensors
  • improved arming checks code to detect a lot more error conditions, and change the ARMING_CHECK default value to check all error conditions.
  • added support for BBBMini Linux port
  • increased number of AVR input channels from 8 to 11
  • auto-set system clock based on GPS in Linux ports
  • added SBUS FrSky telemetry support (thanks to Mathias)

IMU Failure detection

Perhaps the most important change for this release is the improvement to the detection and recovery of bad IMUs. We have had a number of reports of bad IMU data in flight from both the mpu6000 and lsm303d. Where possible the drivers how try to detect the failing sensor and reset it. Sometimes it can't be reset, in which case it will be locked out and the other IMU will be used, unless it is the last available IMU, in which case it will still be used. In either case the user is notified of the failure via the GCS so they can land.

UAVCAN support

The main new feature in this release is support for UAVCAN ESCs, GPS modules, compasses and barometers. Note that while support is in for UAVCAN ESCs and I have been flying with a UAVCAN ESC on my test plane for a few weeks very successfully, support for configuring the ESC is still fairly basic. You will need a debug cable to connect to the ESC to configure it as per the website. We hope to add MAVLink enabled configuration soon.

Many thanks to everyone who contributed so much to this release with bug reports, patches and suggestions. My apologies that we didn't get everything done that we wanted to get done. We have pushed some things out to the next release to prevent the release date sliding back any further.

Happy flying!

David Rowe: Codec 2 and GMSK over VHF Radio Part 1

Thu, 2015-02-05 15:30

In the previous post comparing GMSK modem algorithms, I had some results suggesting we can build a Codec 2 VHF “mode” that outperforms legacy analog FM by 10dB (that’s a factor of 10 in power). It seemed to good too be true. So for the past few weeks I’ve been working with Daniel, VA7DRM, to test these ideas using real radios.

The Experiment

Starting with the “ideal” GMSK modem I developed in the previous post, I added the various building blocks required to make it operate over a real radio channel. For example initial frequency offset estimation, timing estimation, fine frequency and phase tracking, and frame sync.

Meanwhile, over in Canada Daniel has set up an experimental system to enable testing the modem over real radios. Here is a block diagram and photo:

We use a multi-mode 2M radio as the transmitter. We use it in SSB mode to play the GMSK modem signal over the air. In this mode, it’s up-converting the GMSK modem signal from a low IF of 1500Hz to 146 MHz. The GMSK modem signal is about 1200Hz wide, so fits neatly in the SSB radio passband.

We don’t use the radio in FM mode for GMSK as my work in the previous post shows that is how you build a crappy GMSK modem.

The tx is switched to FM for sending FM test signals. The SNR of the system is adjusted to be exactly the same for GMSK and FM.

A RTL style SDR dongle is used as the receiver in both modes. By adjusting the rx gain we can set up the SNRs we require to perform our tests. The gmsk.m GNU Octave simulation pops out a file of errors that can be used to simulate Codec 2 over this channel. The end result is we can listen to Analog FM and Codec 2 over GMSK for a range of channel SNRs.

I send a fixed frame of test data over the GMSK modem rather than Codec 2 data. A fixed frame makes it easier to measure bit error rates and do frame sync. I XOR the transmit an received bits to get an error pattern which can be used to simulate the exact effect of those bit errors on the Codec 2 bit stream. I actually cheated and used the 1300 bit/s Codec 2 mode instead of 1200, as it’s somewhat more robust to it errors. This is worth 0.35dB over the channel.

Here is a spectrogram (sideways waterfall) of one of the test samples from the SDR:

The GMSK signal is centred on 1500 Hz on the left. On the right is the FM signal, centred on a 12 kHz carrier. The FM signal is about 16 kHz wide, so we needed a higher centre frequency. First we send a 1000 Hz test tone, after FM modulation that produces the lines you can see in the FM spectrum. Then we switch to a sample of Daniel’s voice. That’s the fuzzier FM signal, as the carrier is bouncing all over the place.

The keenies will notice a small bit of DC at the lower far left hand side. That’s the nasty DC offset you get from SDR radios when the IQ balance is a bit off. It fades away as we nail it with a high pass filter. If it’s too high it upsets our GMSK demod.

If we average the spectrum over the entire run we get:

Note how much narrower the GMSK signal is than FM. This sample is for the C/No=43dB run in the table below.


To measure SNR requires a known noise bandwidth (e.g. 3000 Hz is common for HF SSB). However the bandwidth of the GMSK and FM signals is different. If we used a 3000 Hz noise bandwidth the FM signal wouldn’t fit. We could measure SNR using a 16 kHz bandwidth for both signals. However another way is to measure the noise using a 1 Hz noise bandwidth. This is known as C/No, or the carrier power divided by the radio channel noise power in a 1 Hz bandwidth.

The GMSK modem is about 1.5dB off theoretical performance. This is not bad, as it takes into account imperfections with the modem algorithms (e.g. errors in timing and phase estimation) and the experimental SSB radio/SDR signal path (e.g. SSB transmit filter, PA non-linearities). The FM demod software gives us a SNR about 3dB worse than theoretical FM demod performance for a given input C/No, possibly because of a non ideal FM modulator or perhaps under deviation. Once again, that’s acceptable.

Here are the results. Warning – turn down your volume control! The first FM sample is just loud noise. There are a few odds errors with the Codec 2 sample, e.g. it gets “four” wrong, possibly due to clipping of the input sample, or maybe a pitch estimation error. Must look into that some time, sure it can be fixed. Too busy playing modems lately!

C/No Analog FM Codec 2 BER Speex 35.5 Listen Listen 0.035 n/a 37.2 n/a Listen 0.008 n/a 43 Listen Listen 0.00 n/a 53 Listen Listen 0.00 Listen 63 Listen Listen 0.00 n/a

In these tests, Codec 2 is working at a much lower C/No than analog FM, with the system gains predicted gains in the previous blog post. Codec 2 starts to deliver intelligible speech (with some errors) at a C/No of 35dB. By 53dB FM is sounding better (although still noisy), so I estimate the cross over point at 48dB, a 13dB gain for the Codec 2/GMSK system over Analog FM. I suspect we also have a similar system gain over 1st generation, closed source codec VHF digital voice systems like DSTAR and DPMR.

I am interested in your thoughts on the relative speech quality, please feel free to comment. The FM samples sound a bit noisy to me, but Daniel thinks they are about right.

There are a lot of knobs we can twiddle with this spare system gain:

  1. The Codec 2 speech quality could be improved with some more work.
  2. We can do 2 channel, no diplexer TDMA for a 3dB hit in C/No (as we would need to double the bit rate).
  3. We can cover a much larger geographical area. IIRC radio waves get attenuated by 6dB as the distance doubles. So a 12dB gain is 4 times the range, which (Area = pi*r*r) means about 16 times the area for the same power. That would help repeaters, developing world, and emergency communications networks.
  4. We can change the Codec bit rate as the channel C/No improves. Who says the speech quality has to remain static under all channel conditions? For less C/No than required by current FM systems we could run a 8000 bit/s speech codec like Speex (see sample above). A little bit higher and it could sound like Skype (using Opus). Wideband audio on your HT anyone? Or mobile in your car?
  5. We can use power control like cell phones, e.g. tell the far end to back off the tx power. Saving battery and RF interference. Would be really useful for ad-hoc mesh networks too (managing the hidden transmitter problem)

Help Us Change VHF Voice Forever!

The key to our improvements is “we own the stack”. Codec open, modem open, protocol open. No one telling us where we can and can’t experiment. We are only limited by imagination and the laws of physics. By we I mean you – it’s open source.

Two guys half way around the world from each other are working on improving VHF voice by a factor of 10. With second hand laptops running open software, a $20 SDR dongle, Ham Radio, good modem design and a little foil.

This is a once in 100 year opportunity. We really need some help, e.g. VHF radio front end design, Octave refactoring, Octave to C porting, GUI C/C++ coding (also see list of tasks at the end of this post). It’s fun and rewarding work. Do you want to be a part of it? Please email me.

If you can’t contribute technically, here’s the donate button:

Donation in US$:

It all helps! Thanks.

Craige McWhirter: Craige McWhirter: Attaching Multiple Network Interfaces and Floating IPs to OpenStack Instances with Neutron

Thu, 2015-02-05 13:28

There are a number of use cases where you may need to connect multiple floating IPs to existing OpenStack instances. However the functionality to do this is not exposed via the Horizon Dashboard. This is how I go about attaching multiple network interfaces and floating IPs to OpenStack instances with Neutron.


Port Creation and Assignment

When you have your environment sourced appropriately, get a list of networks for this tenant:

% neutron net-list +--------------------------------------+--------------+-------------------------------------------------------+ | id | name | subnets | +--------------------------------------+--------------+-------------------------------------------------------+ | 85314baa-a022-4dd1-918c-a73c83c8cad6 | ext-net | 9248bc58-6cfe-4ff8-b33e-286a60c96c6d 999.999.999.0/23 | | ee31dc0e-e226-423d-a7fe-f564dc17614e | DemoTutorial | 5821de82-3843-46ce-a796-c801bf40fd4c | +--------------------------------------+--------------+-------------------------------------------------------+

We're interested in the non-external network. In this case "DemoTutorial". I normally set this to $OS_NET. Now we can create a new port on that network.

% export OS_NET=ee31dc0e-e226-423d-a7fe-f564dc17614e % neutron port-create $OS_NET Created a new port: +-----------------------+---------------------------------------------------------------------------------------+ | Field | Value | +-----------------------+---------------------------------------------------------------------------------------+ | admin_state_up | True | | allowed_address_pairs | | | binding:vnic_type | normal | | device_id | | | device_owner | | | fixed_ips | {"subnet_id": "af150a1e-067a-4641-89a4-24c5b6b8fe3b", "ip_address": ""} | | id | fd2f78df-cf78-4394-84eb-9e37ed1e5624 | | mac_address | fa:54:6e:f2:ce:a9 | | name | | | network_id | ee31dc0e-e226-423d-a7fe-f564dc17614e | | security_groups | b1240686-7ad9-4d29-a679-d219f76648ca | | status | DOWN | | tenant_id | abcd639c50804cf3end71b92e6ced65e | +-----------------------+---------------------------------------------------------------------------------------+

We now need to note the id or as I do, assign it to $PORT_ID. Next we fire up nova. I'm going to assume that you know either the instance name or ID and have assigned it to $INSTANCE.

% export PORT_ID=fd2f78df-cf78-4394-84eb-9e37ed1e5624 % export INSTANCE=3c7ae1b9-8111-4f15-9945-75e0af157ead % nova interface-attach --port-id $PORT_ID $INSTANCE

You should now have successfully added a second network interface to your OpenStack instance. Let's double check that:

% nova show $INSTANCE | grep network | DemoTutorial network |,

Great! Now you have two internal IP addresses, one for each port assigned to that tenant.

Assigning Floating IPs

You can now add floating IPs either via the Horizon Dashboard or via the neutron client. I'll cover how to do this via the CLI. Fire up neutron, locate the original port and assign it's UUID to $PORT_ID0:

% neutron port-list | grep fa:46:7e:21:4f:f3 | {"subnet_id": "8f987932-48ee-4262-8b44-0c910512a387", "ip_address": ""} | % export PORT_ID0=8f987932-48ee-4262-8b44-0c910512a387

Then we get a list of available floating IPs and assign those to variables too:

% neutron floatingip-list +--------------------------------------+------------------+---------------------+---------+ | id | fixed_ip_address | floating_ip_address | port_id | +--------------------------------------+------------------+---------------------+---------+ | 390e4676-0e05-40c3-9012-e5d27eb85dbe | | 999.999.999.123 | | | 16f7ca27-1d11-4967-9f0c-04f578590b01 | | 999.999.999.124 | | | f983b10d-454c-4c19-8f65-d9b96c4d7aa6 | | 999.999.999.125 | | +--------------------------------------+------------------+---------------------+---------+ % export FIP0=16f7ca27-1d11-4967-9f0c-04f578590b01 % export FIP1=f983b10d-454c-4c19-8f65-d9b96c4d7aa6 % neutron floatingip-associate $FIP0 $PORT_ID Associated floating IP 16f7ca27-1d11-4967-9f0c-04f578590b01 % neutron floatingip-associate $FIP1 $PORT_ID0 Associated floating IP f983b10d-454c-4c19-8f65-d9b96c4d7aa6

We can then verify this assignment:

% neutron floatingip-list +--------------------------------------+------------------+---------------------+---------+ | id | fixed_ip_address | floating_ip_address | port_id | +--------------------------------------+------------------+---------------------+---------+ | 390e4676-0e05-40c3-9012-e5d27eb85dbe | | 999.999.999.123 | | | 16f7ca27-1d11-4967-9f0c-04f578590b01 | | 999.999.999.124 | | | f983b10d-454c-4c19-8f65-d9b96c4d7aa6 | | 999.999.999.125 | | +--------------------------------------+------------------+---------------------+---------+

For good measure you can double check how Nova sees this assignment:'

% nova show $INSTANCE | grep network | DemoTutorial network |,, 999.999.999.124, 999.999.999.125

You're done :-)

Arjen Lentz: Scientists pledge to increase interference with the Church | The Guardian

Thu, 2015-02-05 13:25

Dean Burnett: If the Church can interject on scientific matters, surely scientists can interject on religious ones?

Related Posts:
  • No related posts

Donna Benjamin: For people who use the web

Thu, 2015-02-05 11:27
Thursday, February 5, 2015 - 11:48


Accessibility matters. For everyone. For those of us who build the web, and for those who use it too. All of us.

Here's some great resources that caught my attention in recent days.

Anne Gibson writes that "Web accessibility means that people can use the web." in an article on List Apart about Reframing Accessibility for the Web. It's really good. She advocates creating a test matrix for accessibility and putting the focus back on the technology available, rather than the abilities of the people who use it. This is strong, clear practical advice we should all consider.

Jeremy Fields has repurposed the WCAG and WebAIM reccomendations to create an Interactive WCAG guide. This makes it easy to link to a specific principal or guideline. 

Ollie Campbell highlights some of the ways that older people use the web, and digital devices is different to how young people do, and to be mindful about our assumptions when designing for the elderly.

Discovering these resources pushed me to reframe some recent conversations about meeting accessibility guidelines.  We often get stuck debating compliance details, when really we should be thinking about setting our content free as flexibly and cleanly as possible.  We're not just ticking boxes.  At least, I hope we're not.

Drupal is one of the best content platforms for web accessibility, but it still has shortcomings. Unfortunately, many people who lack the deep understanding of what makes accessibility important still build sites that don't meet WCAG guidelines.  I think it's up to all of us to spend a bit more time getting up to speed on the intricacies, and build it into our practice, and not just meet those guidelines, but exceed them!

[Image from from the W3C's Web Accessibility Initiative Guidelines and Techniques page - Read a description of this image ]

Update 6 Feb: Included Ollie's article on designing for the elderly. 

Clinton Roy: clintonroy

Tue, 2015-02-03 19:28

After a very early start, walked to work.

Had a doctors appointment in the evening.

Basically collapsed into bed quite early. Had half an hour of sleep before waking up from a bad dream.

Filed under: diary

Clinton Roy: clintonroy

Tue, 2015-02-03 19:28

Did a few conference things.

Caught up with a dear friend for dinner.

Filed under: diary

Clinton Roy: clintonroy

Tue, 2015-02-03 19:28

Humbug day, with both the lca debrief and the election, double excitement! Unfortunately my partner in crime, Russell, had to attend to an emergency situation and couldn’t stay for the debrief, a large part of the enjoyment I get out of the debrief is disagreeing with Russell. Fortunately Tomas stepped in and added a great deal of information including a number of talks that I never would have bothered looking at, which is after all the entire point of the debriefs.

Filed under: Uncategorized

Jonathan Adamczewski: What’s the difference between 0xffffffff and 0xffffffffu?

Tue, 2015-02-03 09:27

In C++, what is the difference between 0xffffffff and 0xffffffffu?

This one’s pretty easy to answer with this information from the C++ standard:

The type of an integer literal is the first of the corresponding list in Table 6 in which its value can be represented.

0xffffffff is a hexadecimal constant, it’s too big to be represented in a (signed) int, so — by the terms of the standard — the type of 0xffffffff is unsigned int.

Furthermore, each of these hexadecimal literals will have a different type:

0x7fffffff // int 0xffffffff // unsigned int 0x1ffffffff // long int (or long long int) 0x1ffffffffu // unsigned long int (or unsigned long long int)

But to answer the original question, there is no difference between 0xffffffff and 0xffffffffu apart from this:

@twoscomplement One is a commonly used curse when the compiler screws up.

— Colin Riley (@domipheus) January 30, 2015