Apples 2010 New iPhone 4 and the new stories

Tracking Steve y from wwdc 2010 on engadget. For what else but to see what new stories they come up with this time.

As usual there is the marketing sweet talk from Stevey. Now if you cut all the crap and look at reality the buckets are

**** Good (not necessarily first, but still good to see)
* using frame as part of antenna system
* not blindly uping the megapixy but do sensible thing ie keep megpies in check but try and improve quality (not sure how many remember Palms vga camera in their mobile which was a similar strategy from them eons back ie quality over blind quantity )

**** the gas (nothing new, but as usual nice stories/spin from Steve)
* retina display – natural progression from the already existing 800*480 phones from other vendors
* A4 – good Arm core like any other current gen Arm core
* Multitasking – finally some sense went to appy, but still some more work left
* ibook – ebook reader, less supported format than others out there. And potentialy locked. (My prayer, Oh God, don’t let Apple fanboys kill the EPaper based ebook readers by the stupid Buzz that Apple and some of their blind zombies generate)
* video calling and 2nd camera – even in India where iphone comes 1 year late and almost locked and at a premium, NOKIA had the support for standards based video calling even before 2007 (ie even before apple iphone was born)
* iads – ads been there for ages, and even interactive ads have been there for long time in other CE device domains and in mobiles sometime back
* thinner phone – natural progression from all companies. And don’t forget no physical keyboardy.
* video editing – as usual new in apple universe, but pretty old in other vendor mobiles
* Gyro – natural progression, already used in other device domains

Conclusion, Nothing new or great here, but still have to give it to them for taking the less traveled path wrt Antennae design and Camera.

Rather than the stupid marketing spin of Retina display, they could have been technically path breaking if they had actually brought something like the PixelQi LCD+EPaper display into their product.

Have to give it to Google, as it stands now, they are in a better position with their Android platform in the mobile phone market. And Nokia, please wake up and come out with some good high end phones including Linux based (Meego or Android (why not), now that you have killed Maemo).

(Tried Google buzz for Appy Steveys’ 4th iPhony, updated a bit for here)

Short and simple commandline Bluetooth in any new Linux distros

Yesterday I had to transfer some files/S60 Opensource programs to my Nokia 6630 mobile and so picked up my usb bluetooth dongle (after ages) and connected to my Linux PC to achieve the same. I had forgotten the things which I had done long time back to get it working (Also one of these days I have to find out where I had noted those steps down).

Either way I started by remembering that I have to try and use obex logic to put those files on the mobile (now come on remembering that isn’t that difficult;-). Soon I remembered most of the things to do through aptitude search/show bluetooth/bluetooth packages, dpkg -L <bluetooth related packages>, some trail_N_error and net searching (googling).

But to my horror what ever I do the connection wouldn’t establish has the bluetooth stack on the PC wasn’t pickup the PIN which I just configured on the PC. After some more rtfm and dpkg -L bluez-utils and cross verification on the bluez website I realised that the way the PIN to be used is specified to the bluetooth stack has changed on the PC and now instead of the pin_handler it uses a dbus based passkey handler. So I compiled the given passkey_agent.c and resolved it. And thus could achieve the file transfer without going into windows thou with some deficit of sleep 😉

So here are the commands one could use to work with bluetooth devices in a linux based pc =>

hciconfig
– Gives info about the bluetooth hci on your pc
– Ensure the device is up and running and has required scan modes
– hcitool dev should also give some of this info

hcitool inq and hcitool scan
– Gives info about or rather identifies nearby bluetooth devices

hcitool info <BTAddr>
– Get info about remote bluetooth device

l2ping <BTAddr>
– One way to see if we can communicate with a remote bluetooth device

sdptool browse <BTAddr> or sdptool records <BTAddr>
– Gives info about the services provided by a remote bluetooth device

obexftp –nopath –noconn –uuid none –bluetooth <BTAddr> –channel <OPUSHChann
elNo> –put <FileToPut>
– Allows one to send file without specifying the pin on the remote device side
– The OPush channel number for device is got from sdptool above

passkey-agent –default <Pin>
– Pin specified here is what the remote BT device should provide
or its user enter on that device when requested.

obexftp -b <BTAddr> -v -p <FileToPut>
– Allows one to put a file onto the specified BT device
– obexftp could also be used to get or list the files on the BT device
– also allows one to identify a nearby BT device by just giving -b option

obexpushd
– Allows one to recieve files sent from a bluetooth device.
– Depending on who started it, the recieved files will be stored in the corresponding home directory

Note: The old style pin_handler doesn’t work with latest bluez, you require a
dbus based passkey handler and there is one provided by default by bluez-utils
called passkey-agent
Hope this helps anyone who is trying to use bluetooth devices from the commandline on a new linux distro, as well as it would help me to remember for the future for my own use.