Following the debranding of the Nokia N95 8GB, updating the phone's firmware, and reconnecting it to the TomTom Rider, I managed to set up the connection.
In June, I performed a real life test. With the TomTom, the phone, and the motorcycle, I went for a trip abroad. Just before I left, I checked the data packet plan for my subscription (Vodafone Live, The Netherlands). At home, it is a flat fee subscription with a fair use policy. Abroad, the packet data connection is causing additional cost. Drivers are: the amount of data transmitted, and a fixed amount for each time (!) a data connection is set up.
Wary of the potential cost, I decided to give it a try. When driving towards the border, everything worked fine. Through the phone's data connection, the TomTom Rider received international traffic information for the whole route to my destination (including The Netherlands, Germany and Denmark). Right after entering into Germany, the TomTom indicated that it could no longer update the traffic information. When driving a motorcycle, this problem is difficult to investigate further. So, after some fruitless attempts at fuel stops, I decided to switch off the phone to save it's battery.
A few days later, on the way back from Germany to home, I switched on the phone again, including the bluetooth connection. After more than one hour driving in Germany, suddenly the TomTom received an update of the traffic information. Again, I could not analyze the cause of this. After crossing the border with The Netherlands, everyhting started to work smoothly again.
Ever since, I have used the TomTom with the phone for a number of rides in the country. The traffic information on the TomTom is not always refreshed. Sometimes, the bluetooth connection with th phone is causing problems, sometimes there is another, unknown cause.
Looking at a number of aspects, I have come to the conclusion that obtaining traffic information (along with other types of data) through a mobile phone's packet data connection is inferior and a potential driver of considerable cost:
- The traffic information service provided by TomTom is paid-for.
- Most phone subscription data plans will charge additional, pay-per-use type of cost when using the data connection abroad. Note that the TomTom will attempt to refresh traffic information every 15 mins or so.
- The bluetooth connection with my Nokia N95 8GB is still dodgy. I feel that the Nokia is more to blame than the TomTom, but still
- Why create a subscription service for traffic information when there is TMC available in most Western European countries? TMC is free and pretty accurate (at least for the country you are driving in at that moment). Most navigation devices using TMC have a separate tuner that "round robins" all FM-stations for TMC-information. This makes the information less vulnerable to a single source failing, and makes the refresh rate of the data effectively better than every 15 minutes.
For those reasons, I decided to buy a TMC-enabled navigation kit for the car. Since only a few of their top range models sport this feature, TomTom lost this battle from the competition: I bought a Navigon 7110.
For some time, I had been trying to use my Nokia N95 8GB with my TomTom Rider 2nd generation.
The TomTom is a complete navigation appliance that can connect with many phones through bluetooth. Not only can it access the phone functions so that one can make phone calls while riding the motorcycle (!), but it can also access the phone's data link so that it can retrieve traffic information, weather, buddies, and the whole lot.
With my previous phone, a QTEK 8310, connectivity with the TomTom worked without flaws. The new Nokia caused problems, as did the Sony Ericsson bluetooth headset that was supplied with the N95.
Finally, I decided I would give it another try.
Using the Tom Tome Home software, I gave the Tom Tom Rider a new version of the software. That resulted in some new features, and an improved user interface.
The communication problems were probably caused by the Nokia, so I tried to install new firmware. Nokia has a designated toolkit for that, the Nokia Software Update Tool. For convenience, this does not work on Vista PC's. My Nokia was branded by the operator, meaning that 15.x was the latest firmware available. For the unbranded phones, there is firmware 20.x. The new firmware includes "automatic screen rotation" and a number of bug fixes.
After some doubts, I decided to go for the latest firmware. This requires some tweaking, in order to "debrand" the phone. Note that we're not cheating the phone operator here, as I will continue my subsscription. With the updated operator code, the software update tool detected a new firmware version. After some time, it was installed. Note that this comes with a few drawcbacks, including a change of menu language and some lost settings.
In both the Nokia phone and the Tom Tom device, I erased all bluetooth device pairings, before I set the up again. After a few attempts, I managed to connect the phone to the Tom Tom. The Tom Tom tries to access the data link of the phone, so the Tom Tom should be leading. Now, the Tom Tom can access all kinds of data services through the phone. Additionally, the Sony Ericsson headset (supplied with the phone) can be paired with the Tom Tom.
During the troubles with the device lock code, I have also attempted to reset the device with a few known tricks for that. Look for some support forum postings on how to do it. Will not reveal it here, because it requires you to push an impossible combination of three buttons while switching the device on.
After I managed to "break" the N95 interpretation of my device lock code, I noticed that the reset attempt had worked. Note that I was never informed before that the reset attempt had worked. The only thing I saw was the device lock key entry box, nothing else. But the reset had worked.
So, I had to spend another hour to restore a backup I made.
Now, I also had to work my way through the impressive list of Nokia-application that was installed on my laptop when I thought I only installed the PC-suite. After some clueless clicking around, and after the Nokia control centre on my laptop decided it had to install a 25 MB upgrade, I found out that I have to use the "Content Copier" application for restoring a backup. A little sidestep: I remember the good old days when backing up and restoring a mobile device could be done with an application that has at least the word "backup" in its name.
Content copier presents me with a sleek black window design, and informs me that not a single backup can be found. My fault, should have tested this before I could expect it to work. It appears that I have to place the backup files back in the place where Content Copier created it. Then, the "open file" dialogue, with the sleek back design, does not inform me that a backup file was found. After some clueless clicking, it appears to be searching folders instead of looking for individual files.
Restored the backup and found out that a number of actions have to be done manually. The SyncML synchronization with the back office needs to be fooled: otherwise the back office system will think I erased some appointments from the calendar, and will also erase them from the back office system for convenience.
Observations:
- What on earth could be in a 25MB upgrade of a dreadful set of tools that do not work properly, neither before or after the upgrade? I would say that this functionality could fit in an 800K executable...
- Whoever asked for a sleek black user window design, that, without my approval, overrules WIndows Vista window settings?
- Why this poor quality, laptop invading, application maze?
- All in all, the whole pc toolkit looks like the Sony Ericsson P900 stuff I used to have. Except that the SE toolkit had a crystal clear, working backup/restore tool with an understandable name, a self-describing icon and a lean user interface.
So far with the frustrations. Maybe focus on the N95's basic function: making phone calls. Have had no complaints about that anymore, since I switched bluetooth off forever. This also helped to reduce the number of "very hard resets" required...
Since a few weeks, I am the owner of a Nokia N95 8GB.
I managed to configure it to match my preferences, so I decided to give data security a bit more attention. Previously, I switched on the SIM-lock and the device lock functions. The device lock is a code that blocks the device after it has not been used for a given time (or after the user locks it manually).
The device lock code was a bit too simple, so I decided to change it. I made up a code, entered the old code, then the new code, then repeated the new code and the process was complete.
The next time I tried to unlock the device, it reported failure. I was very sure that I had used the correct code. Also the old (simple) code did not work anymore.
After some time, I discovered what went wrong:
- The new code I made up was a series of 6 digits
- The device lock code is a 5-digit code
- Apparently, the phone accepted my 6-digit code (initial entry and check) but did not use all 6 characters
Question remaining is: what did the phone remember from the 6-digit code I entered? Probably 5 digits (as the device lock code is a 5-digit code), but which 5?
After some attempts (after a few mismatches, you'll have to wait 5 minutes between every single attempt), I found out that: "in case you correctly enter a 6-digit code as your new device lock code, the phone uses the first 5 digits you entered". Makes sense, but I tell you I had a hard time before I found this out.
Probably, this "undocumented feature" is related to the way the codes are stored (hashed, hopefully). However, I wish to express my sincere thanks to Nokia for this user interface flaw that cost me a few hours of work. If ony 5 digits are allowed as a code, why allow more? Why not inform the user? Why accept the 6-digit code entered by the user?
And, I am sorry to say that it is not the only issue. The dear N95 requires a hard reset every day. And with a hard reset, I mean that the battery has to be removed and placed back.
[update:] Due to a constant stream of annoying comments asking how the phone's security can be broken, I have decided to switch off comments for this posting. Once and for all: when you don't know the security code anymore, you should go to you reseller or a Nokia representative and prove that you're the rightful owner. Maybe they'll be able to help you. I can and will not help you with this. [end of update]
Restored some references to images belonging to earlier post. Apparently, the references were lost during some archiving action by Geekswithblogs. Thanks, Thiago!
Microsoft are working on BizTalk Server 2006 R2. Remarkable news was the announcement of a specialist application for RFID, based on BizTalk. The product is called BizTalk RFID, and is included on the installation media of BizTalk Server 2006 R2.
Now, what is this?
In RFID-terms, I think BizTalk RFID is best described as "edgeware". It is meant to sit close to RFID-hardware and related things like printers, actuators and signal lights. This is the RFID-equipment on the shop floor. BizTalk Server 2006 can be used for back-end side integrayon of things.
Traditional problems with end-to-end solutions including RFID hardware is the lack of standardization and the absence of device drivers / controllers for the devices.
Already earlier, many parties have recognized problems related to volumes and grain of detail of data produced by an RFID-landscape. This can not directly be handled by the enterprise (ERP) back end. There are clever products available that can do filter and combine the huge volume of data produced by the RFID-equipment. Only relevant information is exchanged with the enterprise back end. For advanced filtering and combination of RFID-data, a highly configurable produc is required that can persist data (in a dedicated database). This is what I see as RFID-enabled middleware.
A number of RFID-enabled middleware products are meant to be used at HQ-level (i.e. close to the enterprise back end). For large scale RFID-landscapes, there is a need for site-level functionality. Furthermore, the connectivity between middleware and RFID-equipment remains problematic. Vendors of RFID-equipment and middleware point at each other as the best party to produce and maintain the device drivers that will make their products work together.
Now, there is BizTalk RFID. A slim application based on BizTalk Server 2006 R2, that will be distributed along with BizTalk Server 2006 R2. BizTalk RFID is not a full BizTalk server. It offers a number of important features:
- Connectivity with RFID-hardware and related equipment. It is said that connectivity with hardware representing ~80% of the market will be in place when the product is released;
- Connectivity to the back end. The product has interfaces for accessing SQL Server and for consuming and publishing web services;
- Customization possible through the rule engine. This is a somewhat elaborate way of telling the application what to do (already known from other BizTalk-releases). The philosophy behind the rule engine is that "business consultants", who know how the application should behave, not how this is implemented in a technical way, can use the rule engine user interface.
Microsoft see BizTalk RFID acting on DC-level, as the "edgeware". At HQ-level, there will be real middleware (ok, why not BizTalk Server 2006 R2) that connects to the back end. It is said that the pricing model for the products will reflect this.
This is a promising initiative. BizTalk RFID clearly fills a known gap in the RFID-landscapes. Microsoft is powerful and resourceful, and is capable of setting the market standards (for back end integration, something that no other party managed to do so far). As usual, there is a huge incentive to go and use a few other of the Microsoft-products: SQL server and BizTalk Server 2006 R2. Nothing really wrong with that, I would say. If you don´t want to use them, don´t go for BizTalk RFID.
BizTalk Server 2006 R2 has a beta-program. See this link.
Because I will change jobs per Januari 1st, I will be moving away from the BizTalk projects and operations. I will no longer blog about BizTalk.
An existing orchestration, that reads Siebel-messages from an MSMQC-queue, maps them, and posts them to a remote http-server had to be upgraded. Together with the upgrade, the performance had to be reconsidered, as the orchestration would be dealing with an increased number of messages.
We did some stress tests and found out that it was easy to get the remote http server into trouble. For a test, we dropped ~20 or more message files in a directory on the file system. This directory is read by a test orchestration that posts the messages in an MSMQC-queue. As of that moment, the upgraded orchestration receives the messages out of the queue, processes them and posts them. Because we drop many files in a directory, and because BizTalk launches separate threads for each message, all messages are processed in parallel threads. It appears as if they are being processed in parallel.
At the end of the orchestration instance's life, the target message is posted to the remote http-server. An interesting thing happens here: on the socket level, the http-adapater only can have one connection (per from-address:from-port to-addres:to-port used) active at the same time. Thanks to http and the underlying network protocols, the transfer of multiple messages to the other side is “multiplexed” in a single http-connection. This was clearly too much for the remote http-server, when we tried ~20 messages.
Because the capacity of the remote http-server could not be extended easily (license issues), we decided to solve it on our side. The idea was to change our orchestration into a “single-instance orchestration”. This is an orchestration (subscribing to the same message type as usual) that can only have one active instance at the same time. This achieved by:
- Adding an additional receive shape. Based on the “activating“ receive shape at the beginning of the orchestration, a “non-activating“ receive shape is added, that receives the same message, and is connected to the same port. The new receive shape is added as the last step in the orchestration.
- Because we have two receive shapes for a single message, we need to add a correlation set. The first (original receive shape initializes the correlation set, the second (added) one follows the same correlation set.
- As correlation type, we take a trivial (i.e. constant value) element out of the message type, that we promoted.
- A loop shape is added to the orchestration. The argument is set to true, meaning that it is an endless loop. All shapes in the orchestration, except the first receive shape, are moved to the inside of the loop.
This is what happens:
- After the orchestration has been started, the BizTalk messaging engine waits for the messages it subscribed to, as usual.
- A new message fires up a new instance of the orchestration. The message is processed as usual.
- Due to the newly introduced receive and loop shapes, the orchestration instance does not end after processing the first message. Instead, it will let the second receive shape wait for a new message that has the same (trivial) promoted property value.
- When a next message comes in, the loop shape takes care that the process is run again.
Please note the following:
- When, for some reason, the started orchestration instance is terminated, a new instance will automatically be started once a new message comes in. The correlation mechanism will again take care that only one instance is active at the same time.
- This mechanism is a form of serialization, i.e. instead of a multithreaded, parallel form of processing, the messages are processed one at a time. This also affects the behaviour of the whole process when the orchestration “hangs“. No more messages will be processed.
- Even though there is serialization, no assumptions can be made about the exact sequence of the messages being processed. For that, you would require an “ordered delivery“ mechanism implemented. This is usually done with MSMQT.
- A delay-shape somewhere whithin the loop-shape will assure that in between delivery of two consecutive messages to the outbound port, there is a desginated, minimal time interval.
- With multiple destinations (like three different url's to post to, depending on three different customer numbers), you could use the customer number in the correlation type. This will lead to each customer number having its own orchestration instance. This means that per customer number (and per url) the messages are processed one-by-one. Still, the three orchestration instances operate in parallel, and are not blocking each other's progress.
- When you consider applying this “serialization“ method to an orchestration that already applies correlation sets, some complications might arise. BizTalk will not allow you (design time) to enclose the receive shapes in a loop shape. The reason is that a receive shape that initializes a correlation set is only allowed to be executed once (per orchestration instance). Because the loop shape will change the orchestration instantiation from “once per message“ to “single instance“, you have an issue here.
- To avoid this potential problem, you can decide to leave your original orchestration unchanged (“one instance per message“). The outbound messages should be written to some sort of a queue. This can be an msmq-queue, or a folder on the file system. From that queue, a dedicated serialization orchestration reads the messages and sends them out one-by-one. Example: see below.
For a project, I have been setting up a schema using the flat file extension. The file to read looks like a modified Edifact message. This is what it looks like:
PNA,H123
LIN,2,XYZ0001
RFF,REFNO01
IMD,C,CODE1, VALUE1
IMD,C,CODE2,VALUE2
IMD,C,CODE3, VALUE3
The schema was created so that it reflects the structure of the message. For reading flat files, a few things had to be changed:
- Add the flat file extension to the schema
- Set the tag-identifier for each record that can be in the flat file (note: some additional group nodes were added to allow for 'group repeat'
- Set the child delimiter character, type and order for all nodes in the schema
A good indication about the effects off all settings can be obtained by using “generate instance“ every now and then. BizTalk should generate a “native“ (flat file) instance.
After some changes, the generated instance looked ok. Then I tried it the other way around: with a given example of the file, try to validate the instance. After I had resolved a few bugs related to the child delimiter settings, I continued to have errors. The parser reported messages like:
Unexpected data found while looking for:
'ERC'
'\r\n'
The current definition being parsed is LINgroup.
All problems were related to the optional, repeating records.
A blog entry gave an important hint. The “Parser Optimization” property (of the Schema node) has to be set to “Complexity”. The default setting (”Speed”) can not handle the optional, repeating records.
The SMTP adapter can be used to send messages to email addresses.
By default, the SMTP adapter comes with few options:
- Note that BizTalk is no mail server. The SMTP adapter can connect to a mail server. So, to be able to send the mail out, you need a mail server as well.
- You can control the “subject“, “from” and “to“ fields of the mail in a static way by defining them in the send port.
- With the “from“-field contents, your mails server might have problems. Most mail servers do not accept mail relaying, which is sending mail on behalf of an address / domain that is not related to the mail server.
- Multiple email-addresses are possible in a single field. You should be using a separator that is recognized by the mail server forwarding your mail. Usually a comma or a semicolon are separators.
- Remember always to use a send pipeline that includes an smtp-encoder in the port definition. When you leave out the smtp-encoder, the message will be sent as plain text in the body of the email message.
- Using the smtp-encoder, only a single message attachment can be linked to the email. You can not really control the name, extension, mime type of the attached message.
For the advanced applications:
- Multiple attachments are possible. This is a so-called multipart message consisting of a body and more than one attachments. You will have to populate the whole multipart message in the BizTalk orchestration. The smtp-adapter then transforms that into a real email message, exactly following the multipart-layout you defined.
- Many of the parameters of the email can be set dynamically in an orchestration. Please have a look at various weblog-posts on the net.