Forum Nokia Blogger Antony Pranata writes about “How to start Symbian C++ development?”. A good read for anyone interested in symbian C++ development, but doesn’t know where to start. As someone who has given thought to developing symbian applications, it was nice introduction to “the tools of the trade”. Bookmarked!

I haven’t been able to post much on the blog this past week courtesy of my finals: “3G Wireless Networks” and “Network Processors”.

But enough is enough! I must concentrate on posting, err.. studying.

I’ve recently had the “pleasure” of updating my phone via the infamous NSU. I was really scared of bricking my phone and I made sure I followed the instructions EXACTLY as specified by the NSU. Even though I was precise, there were problems. I mean, the f/w update went well, but the hard disk got corrupted. That meant transferring nearly 2 gigs of songs, re-creating the playlists, installing all the apps and so on.

The main cause of concern in the entire update process is said the be the cable and the connector. Loose connector/bad cable == bricked phone in most of the cases. Another reason why people have ended up with bricked phones is due to small things like for example, they tend to forget to change the profile to the General Mode. So if you think about it, the problem lies with people and the hardware. The software looks like its inherently bug-free, right?

WRONG!

If you look at post here on HowardForums, Nokia says that they haven’t released any updates for the N93 because of “issues with the NSU” which results in bricked N93s.

So in a process which can be described as: Phone -> Cable -> NSU software, not one of these components can be called reliable. So a user can end up with a bricked phone and not know the exact reason as to why it was bricked. A user CAN ensure that the settings in the phone are correct, he CAN ensure that the cable is good and the connectors are not loose, but there is NO way a user can safeguard against bugs in a software he knows nothing about.

This entire process is just too risky for a normal user. I depend on my phone for my day-to-day activities. I cannot imagine the effects of a bricked phone, considering I don’t have a backup phone these days.

I think Nokia should just allow users to download the firmware files and then move them via BT/IR/usb to the phone. Design a symbian updater that works on the phone itself which can change the profiles and settings as it is run, eliminating majority of the issues that lead to bricked phones.

Or if they won’t us to have the the firmware, at the very least,  enable FOTA updates.

I took a look at the AWS spectrum auction that just took place in last couple of months in the USA. The frequencies auctioned off were in the range of 1.7GHz for uplink and 2.1Ghz for downlink. Now, what’s interesting is that Cingular has managed to roll out its very own 3G deployment (in the form of HSDPA for packet data only) in the 850MHz/1900MHz band using its already existing spectrum. Now that cingular has acquired spectrum in the 2.1GHz range why can it not deploy 3G using the 1900/2100 MHz combination like Europe. I mean they would ONLY have to re-plan their entire 2G network to 850MHz and spend like a billion or so dollars :D. But in all fairness, it is a possibility that cingular should consider.

Lots of blogs and forums are talking about a tweak which supposedly increases your GPRS browsing speeds. The tweak involves changing your DNS server address. Now, let me make this clear,

DNS servers have nothing to do with transfer rates.

A DNS server is basically used to convert a hostname/url like “www.abhishta.net” to a corresponding I.P. address like “192.168.1.1″. It will not improve loading times, download rates in any way.

But some users reported an increase in their browsing speeds. How did this happen? Let me explain it to you in brief:

A GSM system uses TDM or Time division Multiplexing, wherein each user transmits in predefined time slots. Since GPRS/EDGE is an overlay over GSM, it works in the same way. Initially, the network starts your connection by assigning you a single slot with the most conservative data rate. As it sees that your bandwidth requirement increases, it will try to increase your data rate by decreasing the coding rate (you still transmit in a single slot) if the channel conditions permit. However, if that is not enough, it will then try and assign you extra time slots to transmit, provided the network is not busy. Thus, your data rate increases gradually as you start your packet data session. So if you started your speed test with the network default settings and found your data rate to be say, 50kbps and then if you changed your DNS settings and re-ran the test, the network knowing that you have an active data connection, will allocate additional resources to you. That’s why you see an immediate increase in your speeds.

I would STRONGLY recommend people to keep the DNS server to the network default as a bad DNS server could lead to DNS spoofing.

Let us take the example of a bank, say for example, Bank of America. Its url is “www.bankofamerica.com” and its actual IP address might be 129.2.24.23 (hypothetical IP address). And this is available in your DNS server. Now, someone comes along and says, change your DNS server to blah blah and you will get better speeds. Trusting him, you do it. In the new DNS server, www.bankofamerica.com is now mapped to IP address 129.24.56.20 which belongs to a hacker. The hacker runs a web server from that IP address and hosts a spoofed version of the bank of america website. And on that duplicate website, the moment you enter your username and password, it gets stored into the hacker’s database and your identity is compromised.

That’s why I will always recommend never to change settings that you don’t know about.