Earlier this year I started Language Spy while fresh from years in a permie job, to bring the fruits of computational linguistics to the masses. The first product - political trend analysis for UK and US politics - made its debut soon afterwards.
Since then a lot of work has gone in to creating and refining the next product, a corpus engine. The hope is to distill this down to app size, bringing the joy of being told something you didn't know about your language to anyone with a phone or tablet. It's been a slow business, creating a map of all that links every word in many gigabytes of text was always going to take a while.
Alongside all that I found myself returning to my past, my training as an electronic engineer. I reclaimed my amateur radio licence and rediscovered the joy of making electronics. One thing led to another and a little add-on board for the Raspberry Pi became the focus of a Kickstarter campaign. OK, the Kickstarter didn't succeed, but it did well enough to demonstrate a market for radio kits on the Pi. And because any small startup needs revenue streams the next step was to investigate selling that board and others on my own account.
As a web developer I bear the scars of many online retail experiences. In short: setting up your own web shop is a huge amount of work, worry, and risk. Been there, done that, and I wasn't going to do it again. I decided to go for a hosted solution, a software-as-a-service shop. I picked Shopify, which for about twenty quid a month gives you about as good a shop as you could hope for. The only thing it didn't do out of the box was print to integrated label stationery, but since Shopify's order printer uses HTML/CSS templates it was the work of about half an hour to make it happen. You only really find out how good an online service is when it goes wrong, but so far I'm pretty chuffed with Shopify.
So the Language Spy shop was born, with the Pi RF breakout board, a direct conversion receiver, and a breakout board for using an Ethernet transformer for small-signal RF work. It's early days yet, but orders have come in and customers have their products.
Of course, there are other ways to sell electronic kits online. And it does no harm to have more than one sales channel. So perhaps it was time to take a look at Tindie. This is an online marketplace for makers, something similar to the service Etsy provides for artists. It's a good idea that seems to have attracted a lot of attention and quite a few kits are available through it.
Logging into Tindie and going through the product set-up process was straightforward. They take 5% of the total price including shipping, which could be better but then again you pay no other fees. I set up the RF breakout board as a product and added shipping zones, but then I found myself wondering whether it was such a good idea.
EDIT, April 2016. When I wrote this piece I raised a concern about Tindie hanging onto your cash for 30 days. Since then I've learned this only applies when you are a very new customer, to ensure you're legit. So there's a whole section removed from my original.
PayPal payments are a minor annoyance. The problem with PayPal is that they're not a bank but an escrow service. A third party who says "Sure, I'll take that money from him and give it to you", without the cast-iron guarantees of banking law holding them to it. PayPal horror stories for small businesses abound, and while I'll use it to buy stuff personally I thus have an aversion to using it for my business. If they could make direct payments I'd be a lot more interested.
The US-centric nature of Tindie is more of a concern. Dollars only and no VAT handling. I need something more friendly to a British accountant and a British taxman.
I really hope Tindie make a success of their venture and I really hope they improve both their payment situation and their handling of international trade. But for now the breakout board on Tindie is in draft mode and I think I'll hold off making it live for a while.
Tuesday, 17 November 2015
Monday, 10 August 2015
Anatomy of a failed Kickstarter campaign
tl;dr: I put a simple electronic kit for the Raspberry Pi on Kickstarter, it didn't succeed. P&P made it look expensive, and I set my target too high. I'm wiser for the experience.
Earlier this year I was using a general purpose prototyping board for the Raspberry Pi as little more than the receptacle for a BNC socket and passive filter to use the Pi's onboard clock generator as an RF source. It wasn't very pretty, with bits of copper wire soldered tot he earth lugs of the BNC socket, and most of the board was unused.
So I had an idea: why not make a dedicated RF breakout board for the Pi, with just enough breadboarding space for a filter, and a BNC socket on board. No rocket science involved, but a handy little niche product. I'd put it on Kickstarter, and have a success on my hands.
A Dirty PCBs order and a 3 week wait for China Post, and I had my boards fresh from China. Their "Protopack" order promises "10+-", in other words a bit more than ten if the process goes well and a bit less if it goes badly. My $10 got me 12 very nicely made boards, which for a prototype service is nothing short of astounding. Buoyed by this and a bag of connectors, I set to work on a set of prototypes and was soon using one of my Pi boards as a WSPR beacon.
All was good. Suppliers sorted, good social media reaction, let's put it on Kickstarter as a kit.
I'm no stranger to product fulfilment. I thus wasn't surprised to read lots of Kickstarter advice about pricing everything to the last fraction of a penny. Horror stories of KS projects who'd not accounted for postage and packing abounded, and I wasn't going to be one of them. So I did my homework, and created an exhaustive spreadsheet of all I'd need, down to the last piece of stationery.
In a quick list, I considered the following:
Earlier this year I was using a general purpose prototyping board for the Raspberry Pi as little more than the receptacle for a BNC socket and passive filter to use the Pi's onboard clock generator as an RF source. It wasn't very pretty, with bits of copper wire soldered tot he earth lugs of the BNC socket, and most of the board was unused.
So I had an idea: why not make a dedicated RF breakout board for the Pi, with just enough breadboarding space for a filter, and a BNC socket on board. No rocket science involved, but a handy little niche product. I'd put it on Kickstarter, and have a success on my hands.
A Dirty PCBs order and a 3 week wait for China Post, and I had my boards fresh from China. Their "Protopack" order promises "10+-", in other words a bit more than ten if the process goes well and a bit less if it goes badly. My $10 got me 12 very nicely made boards, which for a prototype service is nothing short of astounding. Buoyed by this and a bag of connectors, I set to work on a set of prototypes and was soon using one of my Pi boards as a WSPR beacon.
All was good. Suppliers sorted, good social media reaction, let's put it on Kickstarter as a kit.
I'm no stranger to product fulfilment. I thus wasn't surprised to read lots of Kickstarter advice about pricing everything to the last fraction of a penny. Horror stories of KS projects who'd not accounted for postage and packing abounded, and I wasn't going to be one of them. So I did my homework, and created an exhaustive spreadsheet of all I'd need, down to the last piece of stationery.
In a quick list, I considered the following:
- The kit components
- A click-to-seal plastic bag for the kit
- Two pages of printed A4 instructions
- A sticky label for the kit
- A Language Spy sticker
- Two different packaging options: small cardboard box versus bag
- Padded envelope
- Dispatch note/invoice/address sticker stationery
- Different postage options: letter versus parcel, and prices for the different Royal Mail international regions
- Kickstarter's cut
- Between 5 and 10% failed delivery, lost in the post etc.
I priced each of the above in three columns: for 100 kits, 500, and then 1000 kits, and added the VAT as I'm not VAT registered. I made my decisions on packaging and postage: bag not box, and letter not parcel postage. I then put together a sample envelope with all the things I'd be sending and took it to my local post office to check weight and postage rate.
My gut feeling price for the components was about £2.50. As it turned out, that wasn't too far wrong for the 100 quantity, and it dropped below £2 for the higher quantities. The BNC connector was the most expensive component.
The sundries added up to more than I expected. When you are used to printing single sheets without a second thought it's a shock when you tot up the cost of a thousand two-page double sided instruction leaflets.
The biggest cost of them all was postage. Down the street: just under a pound, to Europe, somewhere under £2, USA just over £3, Australia well over £3. I took a decision at this point to charge one flat reward rate. I know Kickstarter have an option for different shipping rates, but previous experience with online shops has taught me that no matter how well you explain and calculate shipping you will always get some customers who manage to put their address in on the other side of the world and select UK shipping. I want to make kits, not argue with people thousands of miles away who can't read.
So taking into account component prices, all the sundries, packing, postage, the Kickstarter cut, and a percentage for lost in transit, I came up with a £9 reward price. On Australian orders I would make not a lot, on US orders a bit more, and on UK orders a bit more than that. I expected most of my backers to be Americans, and this turned out to be the case.
Looking at comparable Pi dev boards, without a BNC they cost somewhere under £5. I would have expected a hypothetical retail version of this kit, probably in the cardboard box packaging and with a percentage for the retailer, to sell somewhere around £6. Let's call it $10, for Americans. Then an online retailer would add about £3.50 P&P. So I wasn't too far from the mark.
If all of the above seems a little too much detail I make no apologies. It's very important to account for everything to turn a gut price for what you think the components might cost into what the finished item is going to cost. Get it wrong, and it'll hurt.
If all of the above seems a little too much detail I make no apologies. It's very important to account for everything to turn a gut price for what you think the components might cost into what the finished item is going to cost. Get it wrong, and it'll hurt.
So on to Kickstarter it went. I set the time for four weeks, and the target for 200 kits. This seemed not too optimistic a target, nor was it a huge amount of money. I put in a early bird offer with a pound off, and away it went.
This was my first Kickstarter campaign. I took as my models the campaigns I had previously backed that I thought had done a good job, and set out to add value, to be responsive to backers, and to publicise without being irritating at it. My social media friends did a sterling job of helping me, I worked on a set of software enhancements for using the Pi as an RF generator, and I wrote a set of updates detailing all the cool things I'd done with the board.
Along the way I had quite a few messages. Three groups: backers, non-backers, and spam from people offering miracle marketing cures to guarantee me a Kickstarter staff pick. The latter I ignored, the former I engaged with. No brickbats on the whole, one or two suggestions for enhancements, a few queries about the price to whom I explained the postage costs and the cost of the same on comparable boards.
Progress started off well. For the first ten days if you'd drawn a ruler along the line I'd have been funded at the three week mark. I was expecting it to tail off into the second week as it dropped from visibility though, and it duly did. A few backers through weeks two and three, then a fresh spate of "rescue your failing project" spam from marketeers. In week four I got a healthy uptick in backers, but sadly it wasn't to be. It was somewhere just shy of 75% when the campaign expired, so no cheque for me to make kits for my backers and no metaphorical cigar.
It's disappointing when something like this doesn't come off. But it's important to retain perspective. My future didn't depend on this project, its development cost me very little and it wouldn't have earned me a huge amount had it succeeded. So it's no biggie, and it was a very interesting process to go through.
So... Where did it go wrong and what would I do differently next time?
There are two areas which I think contributed to the failure of this campaign.
- I set the sales quantity for success too high.
- Postage and packing inflated the price the user saw.
In the first area, there was no reason why I could not have set the bar at 100 kits, and if I had done the project would have succeeded. Pure optimism on my part. If I do another one I'll set the bar at the minimum level to give it that magic high percentage when it comes into visibility again at the end of the time period.
In the second area, there wasn't a lot I could have done to change the reward price. And consumers who are used to making the purchase decision on the item page without seeing the P&P at the checkout were always going to see the reward as a bit steep. If I have earned one thing from this process it is that items costing under a tenner are disproportionately hit by postage costs, if I do another campaign it'll be for a more expensive item.
So there we are. I put up a Kickstarter campaign, it got quite a few backers, but not enough. And I'm still standing. I think the RF board still has a future, though I'm not sure I'll relaunch it in the same place. Watch this space, it could be coming to a website near you.
Saturday, 18 July 2015
A practical antenna testing range
If you have an interest in antennas it can be very illuminating to take real-world antenna measurements. This post describes a simple set-up to allow practical VHF and UHF antenna measurements on a budget.
The first requirement is enough free space as to not cause interference or obstruction to your antenna. As much distance as possible in all directions, ideally many wavelengths. I used a field because I grew up on a farm, but you could use a public park, an empty beach, or common land.
The second requirement is for some means of measuring RF field strength. There are specialist instruments to do this, but for cheapness and practicality in this case I used an RTL SDR, one of those USB digital TV sticks. I plugged it into my Android tablet, ran the SDRTouch app, turned off the automatic gain control, and turned the gain down to about 10% of its range. My receive antenna was the nasty little 15cm wire antenna that comes with the SDR, the only time I've ever used it in action.
The third requirement is a transmitter. Any transmitter for the frequency of your antenna will allow you to take measurements, however for this practical test range you will need it to be capable of micropower output. I used a Raspberry Pi with my RF breakout board and an attenuator network. I calculated that my 47R-470R-47R Pi network resulted in an output around 0.03 mW, or 30μW. This resulted in a detectable RF field that was entirely within the boundaries of my range, in other words the transmitted signal was undetectable 100m from the antenna. For the purposes of legality I used a low-pass filter and a modified version of the freq_pi signal generator that inserted my callsign in CW into a continuous tone once every few minutes.
So, given my three prerequisites, I set to work. I set up my 2m HB9CV antenna in the middle of the field, chose an unoccupied frequency - a part of the repeater input segment not used in my part of the world - and fired up the Pi.
The detection setup was a clipboard with a piece of paper, and the tablet and receive antenna secured with rubber bands. I walked away from the antenna at each point of the compass, noting down the received signal strength at each metre interval.
My resulting figures could then be put into a spreadsheet and rendered as a radius plot to draw the radiation pattern for the antenna. And so I proved by measurement that an HB9CV is a directional antenna. Hardly unexpected, I'm sure you'll agree, but the real proof is that using a £20 single board computer and a £10 USB receiver it's possible to make real-world antenna performance measurements.
Tuesday, 30 June 2015
Measuring SWR with an extreme QRP transmitter
As I've used the prototype RF breakout boards for the Raspberry Pi, I've found one or two unexpected challenges posed by such a low power transmitter. This post deals with one of them, the problem of measuring SWR with not enough power to operate my SWR bridge.
When your transmitter only supplies 10mW of RF power it is extremely important that all components handling that RF do so with maximum efficiency. When you have plenty of power to spare it does not matter if you lose a bit along the way, but when you have so little in the first place your every loss will be felt. You thus need to ensure that your connectors and feeder are as low-loss as possible, and that your antenna has as good an SWR as you can make it. If you have a higher power transmitter on the same band in your shack it will be easy to use that to set up your antenna, but if all you have is a Raspberry Pi you may have to take a different tack from that which you are used to.
This might seem like a blindingly obvious revelation, but a 10mW transmitter does not have enough power to operate a lot of commercial SWR meters. Devices sold for use with watts or more of RF power may not have a range with the sensitivity required to give a reading when supplied with small numbers of milliwatts. My trusty Howes resistive SWR bridge for example is nominally a QRP device, but QRP in that case seems to mean watts in the single digits and it starts to have problems as the power dips under 500mW. When presented with 10mW it gives no meter deflection at all, to all intents and purposes it has become a useless instrument.
My solution when I needed to measure the SWR of my 70MHz WSPR dipole was to go back to SWR basics and use a directional coupler on its own with my multimeter measuring the voltage on its reverse port. My directional coupler dates from my days experimenting with 435MHz ATV, and is a few inches of coupled stripline on a PCB in a diecast box with Schottky diodes feeding its ports. 70MHz is probably not its ideal frequency, but just as an example with the Raspberry Pi as an RF source I measured between about 10 and 100mV on the reverse port increasing with the SWR of the termination. For the record the 70MHz dipole measured 81mV compared with a 50 ohm terminator's 10mV, indicating a poor SWR that turned out to be from a detached co-ax braid connection.
Some more information on directional couplers:
W2AEW video on directional couplers
https://www.youtube.com/watch?v=byF1FLdbUiA
GM8OTI stripline directional coupler for UHF
http://www.marwynandjohn.org.uk/GM8OTI/projDirCoupler/projDirCoupler.html
VK1HW ferrite directional coupler for HF and VHF
https://sites.google.com/site/vkonehw/home/homebrew/Bidirectional-Coupler/building-a-bidirectional-coupler
When your transmitter only supplies 10mW of RF power it is extremely important that all components handling that RF do so with maximum efficiency. When you have plenty of power to spare it does not matter if you lose a bit along the way, but when you have so little in the first place your every loss will be felt. You thus need to ensure that your connectors and feeder are as low-loss as possible, and that your antenna has as good an SWR as you can make it. If you have a higher power transmitter on the same band in your shack it will be easy to use that to set up your antenna, but if all you have is a Raspberry Pi you may have to take a different tack from that which you are used to.
This might seem like a blindingly obvious revelation, but a 10mW transmitter does not have enough power to operate a lot of commercial SWR meters. Devices sold for use with watts or more of RF power may not have a range with the sensitivity required to give a reading when supplied with small numbers of milliwatts. My trusty Howes resistive SWR bridge for example is nominally a QRP device, but QRP in that case seems to mean watts in the single digits and it starts to have problems as the power dips under 500mW. When presented with 10mW it gives no meter deflection at all, to all intents and purposes it has become a useless instrument.
My solution when I needed to measure the SWR of my 70MHz WSPR dipole was to go back to SWR basics and use a directional coupler on its own with my multimeter measuring the voltage on its reverse port. My directional coupler dates from my days experimenting with 435MHz ATV, and is a few inches of coupled stripline on a PCB in a diecast box with Schottky diodes feeding its ports. 70MHz is probably not its ideal frequency, but just as an example with the Raspberry Pi as an RF source I measured between about 10 and 100mV on the reverse port increasing with the SWR of the termination. For the record the 70MHz dipole measured 81mV compared with a 50 ohm terminator's 10mV, indicating a poor SWR that turned out to be from a detached co-ax braid connection.
Some more information on directional couplers:
W2AEW video on directional couplers
https://www.youtube.com/watch?v=byF1FLdbUiA
GM8OTI stripline directional coupler for UHF
http://www.marwynandjohn.org.uk/GM8OTI/projDirCoupler/projDirCoupler.html
VK1HW ferrite directional coupler for HF and VHF
https://sites.google.com/site/vkonehw/home/homebrew/Bidirectional-Coupler/building-a-bidirectional-coupler
Friday, 26 June 2015
Raspberry Pi RF breakout kit on Kickstarter
So, I've done it. Put the Raspberry Pi RF board on Kickstarter. The thing I said I didn't think would work out as it would put me into VAT. In the end I decided I'd have to sell a huge number to reach the VAT threshold so it was worth the risk. Time will tell how good a decision that was.
What have I learned from putting it all together? Everything costs more than you think it will. When I assembled a kit with components, packaging, instructions, a sticky address label, an invoice, and a Language Spy sticker, it really came home how many items I'd have to price up in quantity. And you learn just how quickly those small items can blow your original estimate out of the water.
Putting the pitch together was the easy bit. Writing comes easily to me. The video is more of a slideshow than a video, I felt there was little point trying to shoot an artsy video for an electronic kit. Kickstarter strongly recommend a video so I did one, that's it.
So here I am, all bases (I hope) covered. Kickstarter's fee and a contingency for lost deliveries factored in, the pitch done, and lead times secured from all suppliers. When I Tweeted the board I got a huge response, let's hope that will translate to a funded project.
So please head on over to the Kickstarter campaign, and if you like it, back it!
The link: https://www.kickstarter.com/projects/2001938575/rf-breakout-kit-for-the-raspberry-pi
What have I learned from putting it all together? Everything costs more than you think it will. When I assembled a kit with components, packaging, instructions, a sticky address label, an invoice, and a Language Spy sticker, it really came home how many items I'd have to price up in quantity. And you learn just how quickly those small items can blow your original estimate out of the water.
Putting the pitch together was the easy bit. Writing comes easily to me. The video is more of a slideshow than a video, I felt there was little point trying to shoot an artsy video for an electronic kit. Kickstarter strongly recommend a video so I did one, that's it.
So here I am, all bases (I hope) covered. Kickstarter's fee and a contingency for lost deliveries factored in, the pitch done, and lead times secured from all suppliers. When I Tweeted the board I got a huge response, let's hope that will translate to a funded project.
So please head on over to the Kickstarter campaign, and if you like it, back it!
The link: https://www.kickstarter.com/projects/2001938575/rf-breakout-kit-for-the-raspberry-pi
Tuesday, 9 June 2015
A Raspberry Pi gives me a lifetime DX record
The other day I dug out and dusted off my amateur radio logbook. The last entry was in 1993, a 70cms FSTV test with 2m talkback with a friend a few miles away. I noted at the time that my power output on 70cms was 50mW, and that the test was a failure. The transmitter was homebrew and I still have it, though I think I may have scavenged the output transistor.
It's weird, reactivating a callsign so long dormant. Long enough dormant in fact that what always felt like a rather new callsign is now something of an old-timer. A lot's happened since 1993 in amateur radio, there are some interesting new bands and modes, and I can now use all the HF bands if I want to. I bet that went down like a lead balloon with the sheds-and-allotments nets on 80m! :) But to be honest I'm no longer interested in sitting in a shack at a microphone. I was always in it to experiment with radio and though I spent a lot of happy hours on 2M FM back in the day I'm probably not returning.
Of the new modes that have appeared since I buried my personal amateur radio time capsule, WSPR caught my eye. Extreme QRP and extreme narrow bandwidth, and best of all, possible using just the internal clock generator of a Raspberry Pi. So with a quickly assembled 70MHz low-pass filter and an equally hastily built dipole I put together a 4M WSPR beacon.
It's a while since I had an operational transmitter of my own. This one's only producing about 100mW, but it's still important to ensure a minimum emission of unwanted radiation. When your transmitter is at heart a logic level square wave there is a lot of possibility for harmonics.
I hope it's not a damning admission when I say I was never able to really ensure I wasn't transmitting harmonics back in the day. I had my wavemeter but it couldn't go up into the high harmonics so if I built anything I had to rely on overprovision of low pass filtering. I suspect I was not alone in this and I never had the DTI breathing down my neck so I am happy I got it right.
Now I have something unavailable to me in the 1980s and '90s, an RTL-SDR. I can have a waterfall spectrum analyser view of any couple of MHz slice of spectrum between 25MHz and 2GHz, so I can take a look for harmonics. Of course it's not a calibrated device so it's difficult for me to check relative values even if I turn off the AGC, but I can still check for presence or absence of radiation.
In the room next to the Raspberry Pi, there are the harmonic peaks. Much lower than the carrier, but still there. Half a mile away though, the carrier is just as strong but the harmonics are no longer present. The lower-level harmonics I detected in the same room are not reaching my antenna, the LPF is doing its job. Good, that's what I want to hear.
So, turn on the Pi, run WsprryPi, and keep an eye on the WSPR map to see who spots it. 4M is neither an easy DX band nor a popular WSPR band, so it wan't exactly a surprise when none of the five or so stations active at the time in Western Europe spotted me. But a Raspberry Pi doesn't use much power, so just leave it running.
After two days, a sporadic-E opening. And a single spot, from just north of Madrid, in Spain. Nearly 790 miles to this part of Oxfordshire, for 4M that counts as pretty extreme DX.
So, EA4ETR. The first callsign in my logbook since 1993, the first non-G callsign, and far and away my furthest DX on a difficult band all in one go. And all with a £25 computer and a filter and antenna from junkbox parts. Not a fancy chequebook transceiver in sight.
That for me is what amateur radio should be all about.
It's weird, reactivating a callsign so long dormant. Long enough dormant in fact that what always felt like a rather new callsign is now something of an old-timer. A lot's happened since 1993 in amateur radio, there are some interesting new bands and modes, and I can now use all the HF bands if I want to. I bet that went down like a lead balloon with the sheds-and-allotments nets on 80m! :) But to be honest I'm no longer interested in sitting in a shack at a microphone. I was always in it to experiment with radio and though I spent a lot of happy hours on 2M FM back in the day I'm probably not returning.
Of the new modes that have appeared since I buried my personal amateur radio time capsule, WSPR caught my eye. Extreme QRP and extreme narrow bandwidth, and best of all, possible using just the internal clock generator of a Raspberry Pi. So with a quickly assembled 70MHz low-pass filter and an equally hastily built dipole I put together a 4M WSPR beacon.
It's a while since I had an operational transmitter of my own. This one's only producing about 100mW, but it's still important to ensure a minimum emission of unwanted radiation. When your transmitter is at heart a logic level square wave there is a lot of possibility for harmonics.
I hope it's not a damning admission when I say I was never able to really ensure I wasn't transmitting harmonics back in the day. I had my wavemeter but it couldn't go up into the high harmonics so if I built anything I had to rely on overprovision of low pass filtering. I suspect I was not alone in this and I never had the DTI breathing down my neck so I am happy I got it right.
Now I have something unavailable to me in the 1980s and '90s, an RTL-SDR. I can have a waterfall spectrum analyser view of any couple of MHz slice of spectrum between 25MHz and 2GHz, so I can take a look for harmonics. Of course it's not a calibrated device so it's difficult for me to check relative values even if I turn off the AGC, but I can still check for presence or absence of radiation.
In the room next to the Raspberry Pi, there are the harmonic peaks. Much lower than the carrier, but still there. Half a mile away though, the carrier is just as strong but the harmonics are no longer present. The lower-level harmonics I detected in the same room are not reaching my antenna, the LPF is doing its job. Good, that's what I want to hear.
So, turn on the Pi, run WsprryPi, and keep an eye on the WSPR map to see who spots it. 4M is neither an easy DX band nor a popular WSPR band, so it wan't exactly a surprise when none of the five or so stations active at the time in Western Europe spotted me. But a Raspberry Pi doesn't use much power, so just leave it running.
After two days, a sporadic-E opening. And a single spot, from just north of Madrid, in Spain. Nearly 790 miles to this part of Oxfordshire, for 4M that counts as pretty extreme DX.
So, EA4ETR. The first callsign in my logbook since 1993, the first non-G callsign, and far and away my furthest DX on a difficult band all in one go. And all with a £25 computer and a filter and antenna from junkbox parts. Not a fancy chequebook transceiver in sight.
That for me is what amateur radio should be all about.
Monday, 25 May 2015
A transceiver for not a lot
I've just built a transceiver for the 4M amateur band. QRP(low power) and AM, it's not going to be something I'll work DX with, or indeed given my rural location not something I'll work *anyone* with, but I've had a lot of fun making it.
My starting point was a 2M QRP AM transceiver courtesy of G3XBM, the 'Fredbox'. The receiver is a FET super regenerative design with an RF amplifier to stop unwanted radiation, and the transmitter is a very simple series modulated PA giving <100mW. I used 2SJ310 FETs in the receiver instead of MPF102s, and 2N3904s throughout in the transmitter. Everything else came from my hoard of electronic bits. I can't claim any astounding electronic design innovations as I was following someone else's proven design with a few adaptions when it came to winding coils and a few minor tweaks to bias resistors to get the desired voltage.
The only significant difference from the G3XBM design is the lack of a crystal. Instead I'm using a Raspberry Pi as my frequency generator, running Jan Panteltje's freq_pi software. This controls the Pi SoC's clock generator, and can produce anything from the low kHz to 250MHz. Quite happy working on 70.260MHz.
So there we are. A home made transceiver costing not a lot, and for not a lot of construction time. Rather more satisfying than a twenty quid BaoFeng handheld, I think.
My starting point was a 2M QRP AM transceiver courtesy of G3XBM, the 'Fredbox'. The receiver is a FET super regenerative design with an RF amplifier to stop unwanted radiation, and the transmitter is a very simple series modulated PA giving <100mW. I used 2SJ310 FETs in the receiver instead of MPF102s, and 2N3904s throughout in the transmitter. Everything else came from my hoard of electronic bits. I can't claim any astounding electronic design innovations as I was following someone else's proven design with a few adaptions when it came to winding coils and a few minor tweaks to bias resistors to get the desired voltage.
The only significant difference from the G3XBM design is the lack of a crystal. Instead I'm using a Raspberry Pi as my frequency generator, running Jan Panteltje's freq_pi software. This controls the Pi SoC's clock generator, and can produce anything from the low kHz to 250MHz. Quite happy working on 70.260MHz.
So there we are. A home made transceiver costing not a lot, and for not a lot of construction time. Rather more satisfying than a twenty quid BaoFeng handheld, I think.
Wednesday, 22 April 2015
An inexpensive video RF modulator
My TV set is an ancient Grundig. It's a good telly for its age but nowadays any TV without a SCART or other AV socket on the back is getting rather difficult to connect to newer kit like my DVD player that didn't come with an RF output. No problem, I thought, I'll just plug the DVD into the SCART on the back of my VCR and feed the TV through that. At which point I came up against our friends the copyright owners. I don't think they like people plugging DVD players into VCRs! To stop people copying DVDs to tape, they incorporate an alternating peak white/peak black bar into the teletext lines on the video signal encoded on the DVD. These are the lines that normally sit out of sight above the screen on the TV, you'll only see them move past if your TV loses frame hold. The effect of this peak white/peak black cycling is to play havoc with the VCR's automatic level control, resulting in a signal from the VCR that flashes on and off and is unwatchable. As someone who is just using their VCR as an RF modulator I get caught in the crossfire.
At this point I had several options. (1)Buy a new telly with a SCART socket, (2)Return my DVD player and buy one with an RF output, (3)Buy an RF modulator, or (4)build an RF modulator of my own. I chose (4) because I didn't have the cash for the other three and since it was Christmas I wouldn't have found a shop open to sell me one. I looked on the Web to see if anyone else had built one and couldn't find any information, so here to fill the gap are the details of my RF modulator.
I decided not to build my modulator from first principles. A simple design with a UHF cavity oscillator and simple sound and vision carrier and modulation circuits is not impossible to make using parts from a scrap TV set, but when so many set top devices already have a modulator built into them why bother? Instead I lifted the RF modulator from a scrap Salora satellite receiver I picked up at a radio rally.
RF modulator modules usually conform to a fairly generic design. I have seen almost identical modules from different manufacturers in VCRs, set-top boxes and satellite receivers with a wide variety of brand names over the years. They are usually a shiny tinplate box a bit larger than a matchbox with PCB mounting pins protruding from the bottom and at least one co-axial RF socket on the side. Mine has 2 co-axial connectors, one for the antenna and one for the TV, a small switch to enable a test signal for tuning the TV and a 5 pin PCB header for signal and power. Since it came from a device for the British market it has a 6MHz FM sound carrier and outputs on UHF channel 36. The output channel is adjustable by means of a trimmer screw. If you live somewhere else in the world your local specs may be different, however the principle should be the same.
Before I removed the module from the donor satellite receiver an element of signal tracing was necessary to work out which pin did what on the PCB header. I was fortunate that while the receiver I was using had a dead CPU its main functions were in working order so I was able to identify the power supply pins quickly by powering it up and using a multimeter. The video and audio pins were a little more difficult to trace, while it was pretty obvious which two pins were the signal pins a little tracing of PCB tracks to the video processor and the sound chips respectively was required to be certain which was which.
There now follows a quick description of each pin on my modulator. If you do this, there is no guarantee that yours will be the same, however the generic nature of these modules means that they are usually similar. I have numbered the pins from left to right with the RF connectors on the top and to the left.
Pin 1 Video. I don't know the spec of this input but it is very happy with the 1V peak to peak composite video from the phono socket on the back of the DVD player.
Pin 2 Audio. This pin takes a line level audio input. My module is not a stereo device so this is mono only. As I run the audio through a hi-fi system this doesn't matter to me but I could simply connect both the left and right audio outputs from the DVD to this pin.
Pin 3 +5V modulator power. This pin provides power to the modulator circuit.
Pin 4 Ground. I connected this pin to the tinplate chassis of the module, which also formed the ground for my power supply circuit.
Pin 5 +5V antenna passthrough power. I did not use this pin. In the satellite receiver it was powered by the standby power supply to provide an amplified passthrough from the antenna socket to the TV socket. Since I did not need this function I ignored it.
The circuit diagram of my modulator is shown below.
To power this modulator I built a simple 5 volt regulator using the ubiquitous 7805 IC. I simply soldered a TO220 heatsink to the module case and built the circuit around it. My choice of capacitor values was based on those I had to hand. I also included an LED to serve as a pilot light to indicate that the unit was turned on.
The 7805 circuit was powered from a surplus 7.6v adapter originally designed for an Ericsson mobile phone. There are so many pieces of electronic equipment powered by small low voltage adapters these days that it should not be difficult to find a suitable surplus power supply. Any DC source between 6 and 9 volts should be suitable, though if you do not have a suitable candidate you can buy a universal power supply.
The video and audio pins were simply connected to trailing phono sockets by short lengths of coaxial cable and the whole unit was mounted in a small plastic box with some hot glue.
The performance of the completed modulator is the same as you would expect for the piece of equipment the module came from. Once the TV is conencted to the modulator output and tuned to the test signal the test switch can be turned off and signal applied to the phono sockets. An RF modulated signal is unlikely to deliver picture quality equivalent to a directly fed video signal but in this case the unit performed well and the quality when viewed on my TV was not noticeably different from that of off-air analogue broadcast signals.
In conclusion, this unit provides a quick high quality RF modulator from a selection of junkbox parts.
Thursday, 16 April 2015
The sad state of the Raspberry Pi software ecosystem
When looking at possible channels for a future Language Spy product last week, I took a look at the Raspberry Pi Store. I've been a Pi enthusiast from the moment I heard about the project, indeed the Language Spy political corpus is driven by a pair of them.
The Pi Store is an app store powered by IndieCity which is available both on the web and through an application included in the Raspbian Linux distribution that most people run on their Pi.
I hadn't looked at the store since it was launched, so I was rather saddened to see it in something of a moribund state. Very little activity, an absence of the commercial software that was there when I'd last looked, not a channel that seemed to be going anywhere.
Of course, you might ask why the Pi needs an app store. After all, Raspbian is a Linux distro, and thus has all the huge library of Linux software available for it, at least all that will compile and run on the Pi's limited hardware. And in a sense you'd be right, in that a few seconds with apt-get can satisfy almost your every software need.
But the success of a machine like the Pi depends on more than just using an operating system with a much wider support. Platforms succeed when they create an ecosystem around them, and while the Pi has been very successful at creating a hardware ecosystem the failure of the Pi Store serves to highlight the sad state of its software ecosystem.
In the last couple of decades working in software companies it has been my observation that the most successful new platforms are those with the lowest barriers to development. In the 1990s the PlayStation trounced the cartridge consoles by not requiring developers to stump up for a huge inventory of plastic bricks for example.
In a way one strength of the Pi - its Linux OS - is also its weakness when it comes to the Pi Store. There are so many different paths to Linux development that the Pi Store lacks that crucial low barrier to entry offered by a simple choice. What the Pi Store needs is an "official" way to write code for it. A straightforward community-supported development path encapsulated in a single download from the store which contains everything needed to publish. In fact I'd go further, what it needs is two such routes, one for simple apps and one for more demanding apps, roughly analogous to a framework like Apache Cordova and Java respectively in the Android world. Maybe Cordova on Qt and Qt itself would fit the bill.
Meanwhile it's no use saying "Rubbish, everyone can just use [insert your pet 1337 dev environment here]!" when the people who are slowly becoming advanced users and wanting to code on their Pis might not have the required technical expertise to master all its nuances straight away.
In the way thus described the Pi Store could become a channel with a low barrier to entry. This is not to say that the "official" dev path need be the only one, more of a "You can code how you like for the store but here's a straightforward way to do it".
I won't be developing that Language Spy product first for the Pi Store as it stands, it would not make sense when other channels will give me a much better airing. The Pi remains a platform with some potential for a developer like me, but until some serious attention is paid to its app store I don't see it gathering its own software ecosystem.
I don't know about you, but as a Pi enthusiast I think that's a shame.
The Pi Store is an app store powered by IndieCity which is available both on the web and through an application included in the Raspbian Linux distribution that most people run on their Pi.
I hadn't looked at the store since it was launched, so I was rather saddened to see it in something of a moribund state. Very little activity, an absence of the commercial software that was there when I'd last looked, not a channel that seemed to be going anywhere.
Of course, you might ask why the Pi needs an app store. After all, Raspbian is a Linux distro, and thus has all the huge library of Linux software available for it, at least all that will compile and run on the Pi's limited hardware. And in a sense you'd be right, in that a few seconds with apt-get can satisfy almost your every software need.
But the success of a machine like the Pi depends on more than just using an operating system with a much wider support. Platforms succeed when they create an ecosystem around them, and while the Pi has been very successful at creating a hardware ecosystem the failure of the Pi Store serves to highlight the sad state of its software ecosystem.
In the last couple of decades working in software companies it has been my observation that the most successful new platforms are those with the lowest barriers to development. In the 1990s the PlayStation trounced the cartridge consoles by not requiring developers to stump up for a huge inventory of plastic bricks for example.
In a way one strength of the Pi - its Linux OS - is also its weakness when it comes to the Pi Store. There are so many different paths to Linux development that the Pi Store lacks that crucial low barrier to entry offered by a simple choice. What the Pi Store needs is an "official" way to write code for it. A straightforward community-supported development path encapsulated in a single download from the store which contains everything needed to publish. In fact I'd go further, what it needs is two such routes, one for simple apps and one for more demanding apps, roughly analogous to a framework like Apache Cordova and Java respectively in the Android world. Maybe Cordova on Qt and Qt itself would fit the bill.
Meanwhile it's no use saying "Rubbish, everyone can just use [insert your pet 1337 dev environment here]!" when the people who are slowly becoming advanced users and wanting to code on their Pis might not have the required technical expertise to master all its nuances straight away.
In the way thus described the Pi Store could become a channel with a low barrier to entry. This is not to say that the "official" dev path need be the only one, more of a "You can code how you like for the store but here's a straightforward way to do it".
I won't be developing that Language Spy product first for the Pi Store as it stands, it would not make sense when other channels will give me a much better airing. The Pi remains a platform with some potential for a developer like me, but until some serious attention is paid to its app store I don't see it gathering its own software ecosystem.
I don't know about you, but as a Pi enthusiast I think that's a shame.
Wednesday, 1 April 2015
Automotive manifesto
Cars are crap, these days.
Something has to be wrong, for me to say that. I'm a lifelong motor enthusiast, petrolhead and engineer. Cars are on paper at least, better than they've ever been. Their engines last for hundreds of thousands of miles, they don't rust, and they all handle pretty well perfectly.
So why do I say that cars are crap these days?
A few weeks ago I sat in a new car from a global manufacturer. It's nothing special, most cars from the last decade are to a greater or lesser extent similar. It's got an extremely advanced engine that will return MPG figures impossible a generation ago, it has a galvanised body, and it'll reliably haul a family of four all day in supreme comfort at autobahn speeds.
Yet I am fairly certain that it and nearly all of its model will be headed for the crusher within a decade. Why? Driving it is not the experience we'd expect from a car made a decade or more ago, instead it's a software experience. It has a digital dash whose instruments were as far as I could see mostly on a TFT screen. When you turn the headlights on a switch doesn't complete a circuit to the light, instead its computer sends a signal to the microcontroller in the light to turn on. Same with all the other controls, even the handbrake. Yes, the handbrake, that thing you rely on to stop the car rolling away down a hill, is no longer a cable but a computer
I looked at that car and saw an engineering masterpiece. I'm an electronic engineer, my dad's a blacksmith and I've been around bits of cars all my life. I know how all this stuff works, in intricate detail.
But I also looked at that car and saw something I wouldn't touch with a barge-pole. I know that within that car is something that won't live up to the manufacturer's hard-won reputation for reliability. It may be that digital dash, it may be the microcontroller in the headlight, the one in the brakes, the throttle, or even the network of data cables that carry all that info around the car's systems, but something is going to fail on that car that won't be fixable without telephone number money, and then the car will be junk.
The problem is of course that the manufacturer couldn't care less. The person who owns the car when whatever piece of techno-crap sends it to the scrapheap won't be the person who drove it off the forecourt, because people who are prepared to take the hit of new car depreciation usually do so because they are so desperate to always drive a new car that the money doesn't matter. So the people who keep the manufacturer in business simply don't care about its built-in obsolescence, therefore the manufacturer doesn't care about it either. (I am a rare exception, I've owned my 2001 car from new)
This makes no sense. It's an oft-quoted line, that more energy is used in the manufacture of a car than in its lifetime of driving. Therefore if we can make cars whose engines and bodywork last forever it is irresponsible to throw them away before they are worn out. No, your fancy hybrid is about as green as a coal fired power station if it only lasts a few years.
I can not in good conscience participate in this scheme of car ownership. On an environmental level sure, but also as an engineer, I don't think I want to buy something that's designed to be so unnecessarily complex as to be unfixable, it's just wrong.
So here's my automotive manifesto.
I will buy a car that has in every instance only the technology that is needed to perform the task in hand, not more than is needed. If all that is needed to turn my headlight on is a switch and a copper wire than I do not need a CAN bus and two microprocessors to do it. I am quite happy to pay for the copper wire and carry the marginal extra weight it brings to the car.
I will buy a car that has high technology where it is needed and where its use makes sense. For example a microprocessor is necessary to control my engine or my anti-lock brakes, but is not necessary to provide basic instrumentation.
I will not buy a car that uses high technology to ensure early obsolescence or to lock-in to a dealer network. If your digital dash costs a four figure sum to replace, or if only your dealer can perform service tasks, then you will not see my money and neither will your dealer.
If I can not buy a car that meets these simple requirements then I will not spend a lot of money for a car made in a European, American or Japanese factory. I will simply spend as little as possible on the cheapest pile of Pacific-rim crap-on-wheels I can find, and bin it when it dies. If I do that then I'll have wasted a lot less money than I would binning a fancy car with a dead digital dash.
I'm just one person. My consumer choices don't figure on the radar of a car manufacturer. But I know the automotive frustrations of one can also be the frustrations of many, as for years I kept the Austin Rover faith as they kept churning out frankly awful cars. Where are those Austin Rover factories now? Mostly housing estates, retail, and industrial parks.
I know I won't be alone in walking onto the forecourt of the first budget Chinese carmaker to arrive in my town. Who knows, perhaps it'll occupy the site of the factory where they made that brand new car I mentioned earlier.
The problem is of course that the manufacturer couldn't care less. The person who owns the car when whatever piece of techno-crap sends it to the scrapheap won't be the person who drove it off the forecourt, because people who are prepared to take the hit of new car depreciation usually do so because they are so desperate to always drive a new car that the money doesn't matter. So the people who keep the manufacturer in business simply don't care about its built-in obsolescence, therefore the manufacturer doesn't care about it either. (I am a rare exception, I've owned my 2001 car from new)
This makes no sense. It's an oft-quoted line, that more energy is used in the manufacture of a car than in its lifetime of driving. Therefore if we can make cars whose engines and bodywork last forever it is irresponsible to throw them away before they are worn out. No, your fancy hybrid is about as green as a coal fired power station if it only lasts a few years.
I can not in good conscience participate in this scheme of car ownership. On an environmental level sure, but also as an engineer, I don't think I want to buy something that's designed to be so unnecessarily complex as to be unfixable, it's just wrong.
So here's my automotive manifesto.
I will buy a car that has in every instance only the technology that is needed to perform the task in hand, not more than is needed. If all that is needed to turn my headlight on is a switch and a copper wire than I do not need a CAN bus and two microprocessors to do it. I am quite happy to pay for the copper wire and carry the marginal extra weight it brings to the car.
I will buy a car that has high technology where it is needed and where its use makes sense. For example a microprocessor is necessary to control my engine or my anti-lock brakes, but is not necessary to provide basic instrumentation.
I will not buy a car that uses high technology to ensure early obsolescence or to lock-in to a dealer network. If your digital dash costs a four figure sum to replace, or if only your dealer can perform service tasks, then you will not see my money and neither will your dealer.
If I can not buy a car that meets these simple requirements then I will not spend a lot of money for a car made in a European, American or Japanese factory. I will simply spend as little as possible on the cheapest pile of Pacific-rim crap-on-wheels I can find, and bin it when it dies. If I do that then I'll have wasted a lot less money than I would binning a fancy car with a dead digital dash.
I'm just one person. My consumer choices don't figure on the radar of a car manufacturer. But I know the automotive frustrations of one can also be the frustrations of many, as for years I kept the Austin Rover faith as they kept churning out frankly awful cars. Where are those Austin Rover factories now? Mostly housing estates, retail, and industrial parks.
I know I won't be alone in walking onto the forecourt of the first budget Chinese carmaker to arrive in my town. Who knows, perhaps it'll occupy the site of the factory where they made that brand new car I mentioned earlier.
Thursday, 12 March 2015
The day I was DoSed by Google
I launched my startup this week. On a very modest scale, no debauched parties or penthouse offices on scads of VC money, just me and my laptop in my dad's living room, popping open a bottle of home made cider to mark the event.
Language Spy is the tangible fruit of a seven or eight year side project, creating a searchable corpus of political language. It's driven by a pair of Raspberry Pis doing the numbercrunching and uploading data to Google Cloud Storage buckets from whence the site is served by Google App Engine.
You can see events unfolding through the words used about them, for example the correlation between "Hillary Clinton" and "Email" in the last week of US politics. If like me you're a news junkie, it's compelling viewing.
Unfortunately though if you click the link as I write this, you'll see a Google App Engine quota exceeded message. The site won't work, because I have reached the point at which I can't afford the traffic it's serving and it has exceeded my daily budget.
This traffic spike would be no problem if it were generated by real site users as then I'd be able to monetise the traffic, but sadly it isn't. Instead it's generated by GoogleBot. That's right, being indexed by a search engine has taken my site down. The bot looks at the site, decides it's on some very fast infrastructure, and issues millions of requests per hour.
When I examine my problem, it becomes clear that it has several aspects:
- It's a language analysis site, so it has a *lot* of pages for the spider to crawl.
- Being a language analysis site there are no pieces of language I can exclude using robots.txt, so I can't reduce the load by conventional means. How do you decide which language is more important than other pieces? You can't, at least not when your aim is to have it all open for analysis.
- I can't tell Google to slow down a little, as where I'd expect to be able to do this in Webmaster Tools I get a "Your site has been assigned special crawl rate settings. You will not be able to change the crawl rate." message. I see this as the sticking point, if I could restrict Googlebot's rate I'd be able to keep the site running and take the hit of not being so well indexed.
Right now my only hope lies with a crawl issue report I filed with the Webmaster Tools team, if they can give me control over my indexing rate I'll be good to go. But I can't say when they'll come back to me if ever, so I may just have to come up with a Plan B.
Is there a moral to this story? Perhaps it's a cautionary tale for a small startup tempted to use cloud hosting. Google Cloud Storage has proved very cost-effective for a huge language database, but the sting in the tail has turned out to be how GoogleBot behaves when it sees a cloud server and how per-instance billing on App Engine handles unexpected traffic surges. The fact that it's Google who are causing me to use up my budget with Google is annoying but not sinister, however neither giving me the option to limit my GAE instance count nor slow down the crawl rate doesn't leave me as the happiest of customers.
So yes, I've launched a startup. It's live for an hour or two a day while it has budget, in the morning UK time. Perhaps that will be my epitaph.
Sunday, 8 February 2015
When open source software goes astray
I have just spent about half a day installing and configuring the latest version of Apache Cordova. I've used Cordova for several years now, it remains a great way to write a cross-platform mobile app.
The reason for this article though lies in the first line. I spent half a day simply installing and configuring a mobile framework, I haven't opened an IDE yet, less still written a line of code. Let's consider that for a minute, this is a mobile framework, not an OS distribution! I am guessing I would have spent less time reinstalling Debian than I did yesterday to end up with a few megabytes of mobile project.
Because that's all Cordova is, when you get down to it. A set of ready-to-go mobile projects for each platform that you pull into your IDE and start pushing HTML and Javascript into. And until version 3 that was how it was distributed. Unpack the downloaded archive, pick up the directory for your platform, pull it into the IDE, start coding. Have your prototype app in front of the boss at the end of the day.
Cordova 3 changed all that, and going by my experience yesterday Cordova 4 hasn't fixed it. You install Node, use npm to get Cordova, run a command line to create your project, then another command line to add your chosen platforms and plugins to the project. The project directory has one master www directory in which you put your app code, and a simple command line builds each platform-specific project from that www directory. Putting aside the version and configuration hell that marred yesterday afternoon's install for me it sounds really elegant.
Unfortunately though that is not the way apps are written in the real world. It would be great to write one copy of your HTML5 app and then deploy it to each platform and compile it from the command line on the same computer, but sadly cross platform app development doesn't work that way.
Picture for a minute the office of a typical Cordova developer who produces apps across more than one platform. They may have a Linux box for Android development, running Android Studio or maybe Eclipse. Their Windows Phone apps will be developed on a Windows box with Visual Studio. And finally they will have a Mac running Xcode on which they develop their iOS apps. This is not a choice but a necessity, try asking Tim Cook or Satya Nadella for permission to develop for their mobile platform on the other's OS and you won't get very far. It's possible that the Android apps could be developed on the Mac or the Windows box, but it's still largely true that if you want to do cross platform app development for multiple target platforms you are going to have to have multiple development platforms and more than one IDE. It's not ideal and none of us really want it or like it, but it's the harsh reality of developing software for closed-source commercial platforms.
In that environment Cordova's elegant project build structure is almost completely useless. Putting aside the unfortunate fact that each platform demands subtly different code for its in-app browser, it is impossible to load the generated Cordova projects directly into Android Studio, Xcode, or Visual Studio and develop them from their Cordova build directories because each time the project is rebuilt at the Cordova end the project you see in your IDE is overwritten. So you end up using Cordova's build system to create vanilla projects for Android, iOS and Windows Phone that you copy somewhere else and load into the IDEs before never touching the Cordova build system again. Instead of being an elegant and useful addition to the project it has become an annoyance and a significant inconvenience.
So there's my Cordova rant. It's a bit unfair, Cordova remains a really useful piece of software. In reality I think it would be better to characterise my rant as one against the tendency in open source software to incorporate features not because they make sense for the software itself, but because someone thinks they are a good idea. In the same way that the developers of PHP who are not PHP coders but C and C++ coders seem to be on a mission to turn a sequential scripting language into a clone of C++, it makes sense to them but is increasingly divergent from the use case for the vast majority of PHP developers.
Every open source project risks this pitfall as a side-effect of success. People write software because they want to solve a problem in their lives, but eventually they transition from being the people with a need for the software to being the people who only write it. They lose touch with why and how the end users use the software and imagine that they and not their users know best how it should be used.
There is an obvious difference between the open source movement and the closed source commercial world. But one thing remains constant in both worlds: the customers will dump your product if you ignore their needs and try to dictate to them what they will have. IBM learned this the hard way in the 1980s with the PS/2; the customers and the rest of the industry continued evolving the PCs they already had rather than taking the direction IBM wished to impose on them.
I find it sad that the same tale is played out in the open source world. Open source software could be a rich dialogue between users and developers, instead each successful project eventually loses its way just as commercial entities do. I suppose moribund companies spawn upstart competitors just as moribund open source software spawns vigorous forks, but there are times when the wait for a fork seems awfully long.
The reason for this article though lies in the first line. I spent half a day simply installing and configuring a mobile framework, I haven't opened an IDE yet, less still written a line of code. Let's consider that for a minute, this is a mobile framework, not an OS distribution! I am guessing I would have spent less time reinstalling Debian than I did yesterday to end up with a few megabytes of mobile project.
Because that's all Cordova is, when you get down to it. A set of ready-to-go mobile projects for each platform that you pull into your IDE and start pushing HTML and Javascript into. And until version 3 that was how it was distributed. Unpack the downloaded archive, pick up the directory for your platform, pull it into the IDE, start coding. Have your prototype app in front of the boss at the end of the day.
Cordova 3 changed all that, and going by my experience yesterday Cordova 4 hasn't fixed it. You install Node, use npm to get Cordova, run a command line to create your project, then another command line to add your chosen platforms and plugins to the project. The project directory has one master www directory in which you put your app code, and a simple command line builds each platform-specific project from that www directory. Putting aside the version and configuration hell that marred yesterday afternoon's install for me it sounds really elegant.
Unfortunately though that is not the way apps are written in the real world. It would be great to write one copy of your HTML5 app and then deploy it to each platform and compile it from the command line on the same computer, but sadly cross platform app development doesn't work that way.
Picture for a minute the office of a typical Cordova developer who produces apps across more than one platform. They may have a Linux box for Android development, running Android Studio or maybe Eclipse. Their Windows Phone apps will be developed on a Windows box with Visual Studio. And finally they will have a Mac running Xcode on which they develop their iOS apps. This is not a choice but a necessity, try asking Tim Cook or Satya Nadella for permission to develop for their mobile platform on the other's OS and you won't get very far. It's possible that the Android apps could be developed on the Mac or the Windows box, but it's still largely true that if you want to do cross platform app development for multiple target platforms you are going to have to have multiple development platforms and more than one IDE. It's not ideal and none of us really want it or like it, but it's the harsh reality of developing software for closed-source commercial platforms.
In that environment Cordova's elegant project build structure is almost completely useless. Putting aside the unfortunate fact that each platform demands subtly different code for its in-app browser, it is impossible to load the generated Cordova projects directly into Android Studio, Xcode, or Visual Studio and develop them from their Cordova build directories because each time the project is rebuilt at the Cordova end the project you see in your IDE is overwritten. So you end up using Cordova's build system to create vanilla projects for Android, iOS and Windows Phone that you copy somewhere else and load into the IDEs before never touching the Cordova build system again. Instead of being an elegant and useful addition to the project it has become an annoyance and a significant inconvenience.
So there's my Cordova rant. It's a bit unfair, Cordova remains a really useful piece of software. In reality I think it would be better to characterise my rant as one against the tendency in open source software to incorporate features not because they make sense for the software itself, but because someone thinks they are a good idea. In the same way that the developers of PHP who are not PHP coders but C and C++ coders seem to be on a mission to turn a sequential scripting language into a clone of C++, it makes sense to them but is increasingly divergent from the use case for the vast majority of PHP developers.
Every open source project risks this pitfall as a side-effect of success. People write software because they want to solve a problem in their lives, but eventually they transition from being the people with a need for the software to being the people who only write it. They lose touch with why and how the end users use the software and imagine that they and not their users know best how it should be used.
There is an obvious difference between the open source movement and the closed source commercial world. But one thing remains constant in both worlds: the customers will dump your product if you ignore their needs and try to dictate to them what they will have. IBM learned this the hard way in the 1980s with the PS/2; the customers and the rest of the industry continued evolving the PCs they already had rather than taking the direction IBM wished to impose on them.
I find it sad that the same tale is played out in the open source world. Open source software could be a rich dialogue between users and developers, instead each successful project eventually loses its way just as commercial entities do. I suppose moribund companies spawn upstart competitors just as moribund open source software spawns vigorous forks, but there are times when the wait for a fork seems awfully long.