i've been incredibly busy the past few days, doing rapid 3in x 5in sketches to ensure that the components fit - jorjin's WG7310, telit's UC864, 4x USB (double-stacked), RJ-45, OMAP DIMM module.
sourcing LCD screens is damn hard, btw. four days of messages and phone calls.
gotta go.
good god, OMAP3530 pin multiplexing is complex and convoluted. basically, there are more functions than there are output pins, so you have to set "modes" on a pin, and it routes to one of (seven i think) functions.
start-up initialisation can either be done by u-boot or, if you define CONFIG_OMAP_MUX, by the linux kernel. the linux kernel source is such a dog's dinner that people recommend it be done by u-boot.
so i _think_ i've worked out that the IGEP-v2 has McBSP3 on the default u-boot pins 4,6,8 and 10. that leaves just a bit of wiring, putting 1.8v output as well to one side of the MAX3378 level converter.
i've also discovered that VAUX1 is a controllable output (from the modem! yaay! AT#VAUX=0 or 1) which provides CMOS 2.6v levels, yaay! actually it's nominally around 2.9v which is what's required to power CMOS 2.6v.
so, that's going on the other side of the MAX3378.
bar a few AT commands, i will then have the Digital PCM Audio of the UC864 connected to the McBSP of an OMAP3530, yaay!
next all i have to do is write the device driver...
well, i'm making slow progress. i got a relatively expensive voltage regulator circuit that just required external resistors in order to specify the output voltage: the trouble is that the accuracy required on a single variable resistor is far too low! so, i need to create a series of resistors so i can accurately set 380.godknowswhat ohms.... :)
but for now, the 3x 1.5 volt cells i'm using are so incapable of supplying enough current that it doesn't matter. i finally got that multimeter: when the device is switched on and connected to the internet as a 3G modem, the output voltage from the battery can be seen to slowly drop... by the time it gets to below 3 volts, the Telit modem can't stand it any longer and falls off the edge of the world.
so, i'll need to put the Ni-Cads in place, instead, and for _that_ i am _definitely_ going to get those resistors set up in parallel/series to create the right voltage!
in the mean-time, i'm wiring up the Digital Voice PCM and getting ready to connect it to the IGEP-v2. i've got the level converter (MAX3378) already sorted out. i _thought_ there was a way to power the UC-864-G side of the level converters without requiring a 2.6v power source: oops, it turns out that there isn't one... so, uhhn... i'm going to have to make one. that means either a resistor bridge or... well... i'm considering using one of the GPIO pins from the UC-864-G ho hum...
at least on the IGEP-v2 / BeagleBoard side, there's a 1.8v reference output available (which strictly speaking you shouldn't use, but hey...)
well, this is getting .... interesting. i've bought some MAX3378 level converters, to cope with the 1.8v to 2.6v voltage differences (MAX3378 so that i don't have to worry about getting the direction right).
i'm wiring the UC-864-G Digital Video PCM to the OMAP3530's "MCBSP" - multi-channel buffered serial port. i'm not going to worry about providing the voltages via a stable power source yet, i'm just going to nick the voltages on each side from each device.
i've soldered the MAX3378 onto a prototyping board (0.5mm pitch...) and tested one of them. stunningly, it worked - powered by 3x 1.5v batteries on one side and 2x 1.5v batteries on the other :)
the next step is to write a McBSP audio driver, making sure all the parameters are right, and also mashing omap-mcbsp.c into submission. omap-mcbsp.c assumes that all audio channels will be stereo and variable (KNOT) rate. UC-864-G actually does U-Law, A-Law or Linear Q15, which i believe to be Signed 16-bit (S16 in alsa terminology), and it's specifically 8kbaud and it's definitely mono.
the only bits i'm not sure about are whether i should be setting an external clock (like the pandora) on the McBSP and whether i should be setting inverted-frame and inverted-clock because the UC-864-G defaults to "master" and sends data on "falling edge"...
mmmm :)
i am deeply impressed with both this module and with sequoia.co.uk. ordered yesterday, arrived this morning, it took me until this evening to be brave enough to power it up.
there is a small break-out board which in theory can be used to power up the module and use it: it has a SIM slot, USB-B, 2x 40-pin connectors which are supposed to be plugged into the Evaluation kit.
after carefully reading telit's complete and comprehensive documentation i decided to try powering up the board. the trouble is: i don't have a soldering iron, or any kit of any kind, like i used to when i was 9 :)
but, that never stopped me, so i found a power supply i would never need again and cut off its cable, stripped the wires and then went hunting for some batteries and some sellotape. i did say that i'd carefully read the documentation, so i'd noted that the required voltage is 3.8 to 4.2, but i figured that 3x 1.5 volt batteries that are a bit old should do the trick.
i figured also that even though there are four pins required for input voltage (1-4) and four for ground (5-8) what the heck, let's just try one each. so, making sure that the white-striped cable was connected to + and to pin 1, and black to - on the last sellotaped battery, with slightly shaking hands i put sellotape on the wires so they wouldn't short, and connected the battery.
nothing happened.
ok - so, i had noted something about an "ON" button, so read a bit more. ok, the Evaluation Kit is supposed to pull something "high" says the documentation (turns out this is wrong). looking closely it says PIN 15. ah ha! ok, back to that PSU, cut off a bit more cable, and use it to connect PIN 1 to PIN 15, for 2 seconds.
nothing happens.
ok, maybe that's wrong, then (god help me if it was, i'm thinking, my hands shaking every time i go near this £150 board, which doesn't help). i know: let's go read the UC-864-G "module" documentation, instead of the EVK2 documentation... yep, turns out that the UC-864-G needs *zero* volts for 1 second, not BATT for 2.
rrright - let's try that. WHAHEY! blue flashing light!
at this point, i'm absolutely astounded, but i go fetch my USB cable. plug it in aaaand, wha-hey!
Nov 12 20:12:53 localhost kernel: [283212.672122] usb 4-2: new full speed USB device using uhci_hcd and address 3 Nov 12 20:12:53 localhost kernel: [283212.829747] usb 4-2: New USB device found, idVendor=1bc7, idProduct=1004 Nov 12 20:12:53 localhost kernel: [283212.829758] usb 4-2: New USB device strings: Mfr=1, Product=2, SerialNumber=4 Nov 12 20:12:53 localhost kernel: [283212.829765] usb 4-2: Product: Telit HSDPA Wireless Modem Nov 12 20:12:53 localhost kernel: [283212.829771] usb 4-2: Manufacturer: Telit Wireless Solutions Nov 12 20:12:53 localhost kernel: [283212.829776] usb 4-2: SerialNumber: 000000000002 Nov 12 20:12:53 localhost kernel: [283212.829976] usb 4-2: configuration #1 chosen from 1 choice Nov 12 20:15:41 localhost kernel: [283381.435232] usbcore: deregistering interface driver option Nov 12 20:15:41 localhost kernel: [283381.435304] USB Serial deregistering driver GSM modem (1-port) Nov 12 20:15:42 localhost kernel: [283382.496373] usbcore: deregistering interface driver usbserial_generic Nov 12 20:15:42 localhost kernel: [283382.496452] USB Serial deregistering driver generic Nov 12 20:15:42 localhost kernel: [283382.496495] usbcore: deregistering interface driver usbserial Nov 12 20:15:48 localhost kernel: [283388.475116] usbcore: registered new interface driver usbserial Nov 12 20:15:48 localhost kernel: [283388.475152] USB Serial support registered for generic Nov 12 20:15:48 localhost kernel: [283388.475212] usbserial_generic 4-2:1.0: generic converter detected Nov 12 20:15:48 localhost kernel: [283388.475366] usb 4-2: generic converter now attached to ttyUSB0 Nov 12 20:15:48 localhost kernel: [283388.475389] usbserial_generic 4-2:1.1: generic converter detected Nov 12 20:15:48 localhost kernel: [283388.475493] usb 4-2: generic converter now attached to ttyUSB1 Nov 12 20:15:48 localhost kernel: [283388.475515] usbserial_generic 4-2:1.2: generic converter detected Nov 12 20:15:48 localhost kernel: [283388.475621] usb 4-2: generic converter now attached to ttyUSB2 Nov 12 20:15:48 localhost kernel: [283388.475643] usbserial_generic 4-2:1.3: generic converter detected Nov 12 20:15:48 localhost kernel: [283388.475743] usb 4-2: generic converter now attached to ttyUSB3 Nov 12 20:15:48 localhost kernel: [283388.475782] usbcore: registered new interface driver usbserial_generic Nov 12 20:15:48 localhost kernel: [283388.475787] usbserial: USB Serial Driver core
(Note the USB device there, for the UC-864-G: idVendor=1bc7, idProduct=1004)
at this point, i'm deeply impressed, and highly amused. i've got a jerry-rigged incredibly expensive module wired up with gaffa tape and batteries, and it's all still going hunky-dory.
ok - i'd already put the SIM card in: let's try wvdial:
lkcl@gonzalez:~$ wvdial vodafone --> WvDial: Internet dialer version 1.60 --> Cannot get information for serial port. --> Initializing modem. --> Sending: ATZ ATZ OK --> Sending: ATZ ATZ OK --> Sending: ATE0V1&D2&C1S0=0+IFC=2,2 ATE0V1&D2&C1S0=0+IFC=2,2 OK --> Sending: AT+CGDCONT=1,"IP","pp.internet"; OK --> Modem initialized. --> Sending: ATDT*99***1# --> Waiting for carrier. CONNECT --> Carrier detected. Starting PPP immediately. --> Starting pppd at Thu Nov 12 20:24:33 2009 --> Pid of pppd: 583 --> Using interface ppp0 --> Authentication (CHAP) started --> Authentication (CHAP) successful --> local IP address 10.91.52.238 --> remote IP address 10.64.64.64 --> primary DNS address 10.11.12.13 --> secondary DNS address 10.11.12.14 --> Script /etc/ppp/ip-up run successful --> Default route Ok. --> warning, can't find address for `www.suse.com` --> warning, address lookup does not work --> Nameserver (DNS) failure, the connection may not work. --> Connected... Press Ctrl-C to disconnect --> Terminate Request --> ***** no quoted text found in `rcvd [LCP TermReq id=0x3]' ***** --> Connect time 1.9 minutes. --> Script /etc/ppp/ip-down started --> Disconnecting at Thu Nov 12 20:26:34 2009 --> The PPP daemon has died: A modem hung up the phone (exit code = 16) --> man pppd explains pppd error codes in more detail. --> Try again and look into /var/log/messages and the wvdial and pppd man pages for more information. --> Auto Reconnect will be attempted in 5 seconds --> Cannot open /dev/ttyUSB0: No such file or directory --> Cannot open /dev/ttyUSB0: No such file or directory --> Cannot open /dev/ttyUSB0: No such file or directory --> Disconnecting at Thu Nov 12 20:26:34 2009
awWWw! but - for that brief period (and for the previous one, which was 6 minutes), i was actually able to get online.
i remain very, very impressed.
What's The Big Deal, Then?
Telit's products are fully documented online without requiring an NDA, and the UC-864-G has 3G/HSDPA, GSM/GPRS/EDGE and has a built-in GPS chipset, in a package that's approx 30mm by 40mm by 6mm deep. it runs Python (!) and it's actually a fully-functioning mobile phone module which simply requires connecting speaker, mic, headset socket, an LCD module, 4x4 keyboard matrix, SIM card slot, battery and charger circuitry. then, everything can be controlled via python scripts which you upload to the module. i find this to be hilarious.
oh - they even support direct connection to a couple of webcams / camera chipsets.
but - the most important bit is the fact that it can do "Digital Voice". you don't need even to connect a speaker or a microphone.
so, as a "module", you can put it into "Digital Voice" mode, and then on one of the 4 multiplexed USBSerial devices you can start reading and writing ulaw or alaw CODEC data - direct!
the implications for free software projects such as FreeSwitch, Asterisk etc. are just... startling.
in combination with things like the Texas Instruments 3530 (ARM Cortex A8) such as found on the beagleboard or the IGEP-v2, the design of a smartphone is drastically simplified: you don't need a separate external Analogue sound-mixer chip, you can use the DSP on the TI ARM to do the mixing and the feeding of data to the audio out. or, once you've decoded the ulaw data on the DSP, you could feed it direct to Bluetooth Audio!
you can tell by the fact that i've used bold and at least two exclamation marks that i find this to be really exciting. haven't had so much fun doing hardware hacking since i was ooo 12 :)
Sierra Wireless MC-8790V
The MC-8790V has the exact same capabilities (minus the python!) as the UC-864-G except it comes in a mini PCI-E formfactor. however, the attitude of Sierra Wireless so far is that they are in the business of selling information about product, rather than selling product.
so, in direct contrast to Telit, Sierra Wireless are requiring that an NDA be signed before providing the exact same information that's publicly available from their competitor. without actually saying so, and giving them a chance to respond, i've made it clear that i'm not that impressed.
the person i spoke to said that yes, they do work with this GPL "FreeWare" software (which i had to correct them on) but i pointed out that making it possible to use only the 3G HSDPA "Data" connectivity isn't actually very useful, compared to e.g. accessing and enabling the "Digital Voice" capabilities, or accessing the GPS chipset.
what i didn't say was that i've done HTC Smartphone reverse-engineering, from about 2003 to 2005, and, after spending an excruciating amount of time trying to work out which bit and which sequence powers up a device i'm just sick to the back teeth of it and flatly refuse to work with any manufacturer who won't provide full technical disclosure sufficient to make their product work. WITHOUT an NDA, so that it doesn't conflict with the development of GPL software.
question for any manufacturers reading this: are you in the business of selling product, or are you in the business of selling information about product? if the latter: we, free software developers, are not interested in helping you shift product.
Ericsson F3507g
Available on E-bay for $USD 85 in single units, this item is pretty common as an OEM module in Dell and other Laptops (GNU/Linux users typically only use it for the data capabilities). However, again, what GNU/Linux and free software users aren't necessarily aware of is that it is a 3G / GPS / GSM module which has Digital Voice capabilities.
Ericsson took a couple of days to get back to me, but expressed significant interest in increasing their market share with this type of product.
I indicated that i was delighted to get such a positive response, described how i was still waiting to hear from Sierra Wireless, and that I already had the UC-864-G module in my grubby little mitts, and very much wanted to try out an F3507g without an NDA, via my little USB-to-PCIe converter i trustingly bought from a random supplier in Taiwan :) [it actually turned up, btw.]
so, i have high expectations of hearing from Ericsson's local distributor, and will keep people posted.
The Home-brew Smartphone / Desktop PC Project
The Plan is to make a smartphone capable of being a desktop PC.
hence my interest in these 3G/GSM/HSDPA modules, in plugable's UD-160-A and in DoubleSight's DS-90U. i'm a little unsure as to whether it will be possible to use USB-to-PCIe converters, simply due to the fact that you need some sort of "wakeup" notification of an incoming phone call (to save power).
normally on an ARM CPU you would put it to sleep, with an IRQ wakeup to be triggered on specific GPIO, such as the "on" button and (surprise) one GPIO which the Phone Module throws High on incoming phone call.
exactly how that would be achieved, along with having to maintain power on the USB bus whilst the device is asleep, to keep the PCIe modems awake - i'm not sure.
but: if it turns out that the PCIe modems (plus converter) are cheaper in volume than the UC-864-G, and the project requirements can drop support for "incoming phone calls", then, what the heck.
but - it's all up in the air until i get some documentation and i get one of these PCI-e modules. if the manufacturers won't supply documentation, it's all academic anyway: i'll just go straight for the UC-864-G.
p.s. the IGEP-v2 arrived. still have to decide between that and a beagleboard, and work out how to add a Touchscreen and an LCD! can't have everything at once :)
russell sent a link to a self-tests autism / asperger's test, with associated warning. decided to give it a shot:
that's fascinating. dreadful empathy quotient, but very high ability to determine people's emotional state (mind-in-the-eyes).
such a pity that bloody internet communication (free software development) isn't usually usually face-to-face.
hm. anyone else gonna give this a try? :)
pyjamas has some _fantastic_ names of people who've contributed to it on it :)
2006-2007: James Tauber 2008-2009: Luke Kenneth Casson LeightonOther Commmitters
Willie Gollino - wgollino@yahoo.com Dobes Vandermeer - dobesv@gmail.com Bernd Dorn - <bernd.dorn@lovelysystems.com> Luis Pamirez Erik Westra Jurgen Kartnaller
Other Contributors
Vicente J. Ruiz Jurado Gerard Labadie Stephan Diehl John Lehman G Clinch Kees Boss Oisin Mulvihill Ondrej Certik Laszlo Krekacs Stefan Schwarzer Radoslav Kirov Beni Kerniavsky Henk Punt Mathias Waack Guenter Walser Martin Blais Scott Graham Nick Hackadelic Catalin Patulea JJ Kunce Alexei Sokolov Carl Roach Yit Choong Sujan Shakya Klavdij Voncina Scott Koranda Phil Hands
it's like an international hall of unpronounceable fame. i love it. i'm trying to encourage other people with more syllables than vowels to contribute - anything, even if it's a single docstring line...
All the while I've been bitching about how there are no open phone projects, it turns out that there are at least three:
this latter one gives a complete set of schematics and bill of materials, all GPL licensed.
i'm amazed. it ranks somewhere in the fishpond scum league when you search for "open mobile phone" or other keywords. i only accidentally encountered it when searching for the part-number "ew-wmbgmr01" of a CF WIFI/Bluetooth module!
i accidentally stumbled onto strategy.wikimedia.org recently, and decided to have a go at writing a couple of proposals. one is the distributed wikipedia proposal, in which, it should come as no surprise that it's the exact same idea as recommended in the arse-kicking article.
actually, the other proposal was originally part of the same one, but it became clear that i was basically talking about the wikipedia "API" which is primarily used by "bots". so, i morphed it into a proposal "extend wikipedia API to cover everything that the current HTTP interface can do, please" proposal.
where it all goes horribly wrong
then, i accidentally encountered some proposals that start talking about putting binary blobs into wikipedia pages (wtf??) and my alarm bells went off the scale. there are three that i've found so far, and they're proposing that wikipedia allow java and flash.
i cannot begin to describe how much of an insanely bad idea these are. from every possible angle imaginable, the risks and costs massively outweigh the marginable benefits, and whereever there is a marginable benefit, there are alternative ideas which do the job in a safer way.
at the core of these proposals is that it is more beneficial to be able to write animations into wikipedia pages, to enhance and augment the text and the information being presented.
where the proposals go wrong is that they then advocate that the use of a full-blown programming language, along with browser plugins necessary to run the resultant binary blobs, is a good idea.
the sheer cost to end-users to learn these programming languages, along with the necessary english language skills and the mindset required to be capable of doing programming, is utterly prohibitive. end-users have enough difficulty with the concept of "wiki markup", let alone a full-blown programming language.
advocates of these proposals are finally admitting "that's okay - end-users aren't expected to contribute to these pages (written in java or flash) anyway, so we don't have to care about them".
this is in direct contravention of the goals of wikipedia, and is completely against the whole purpose of the wikimedia strategy process.
exactly why the advocates of these proposals still cannot get this, even though i've been pointing it out to them in a dozen different ways, i really don't understand.
but - i am persisting with explaining it to them because the risk is that their proposals are accepted. i cannot find the words to describe how much of an incredibly bad idea that would be.
works a treat, which is an amazing surprise. the GWTCanvas API basically maps near-direct to SVG, to support all browsers but IE, and then does this weird string-creation trick using the VML namespace, for IE.
what stunned me is that the port of GWTCanvas also works under pyjamas-desktop as well. again, elements using the VML namespace get added (using the COM interface) and it's all hunky-dory.
very cool.
New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.
Keep up with the latest Advogato features by reading the Advogato status blog.
If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!
