I'm having problems with TCP/IP "freezing" with the XDA. What happens is that the XDA stops receiving messages if there's a period of inactivity over the IP connection of about 45 seconds.
The IP connection still works, and I can send messages from the XDA in the other direction, which then "unfreezes" the waiting messages and they then appear at the XDA.
GPRS is still connected throughout.
This happens both with my IP test apps and with MS Messenger. In messenger, if I start a chat with a PC and the person on the PC doesn't type anything for 45 secs, then no further message comes in from the PC until I send a message from the XDA, whereupon I get all the messages they sent to me.
This seems, therefore, to be a bug in the XDA's socket stack.
Is this a known problem and, if so, is there a fix?
I'm running BIOS version 3.12.07 ENG, 08/13/02.
Cheers,
MikeS.
Upgrade your software.
I had the same issue and fixed it by upgrading to 3.16.13 & 3.19.
Thanks bamse - was planning on doing that as soon as I get a smart card reader.
i have various different versions of the radio stack and bios on different devices but none of them are as recent as the versions you mention. can anyone tell me where to get these versions of the bios and radio software? did they come from microsoft or from the device manufacturer, or somewhere else perhaps?
thanks,
nick.
You might want to try this:
http://www.idedata.no/support/support.asp?ID=299
The files seem to be the same for all of the Scandinavian countries (SE/DK/NO), and they work just fine for me in Sweden. I don't know if anyone tried them anywhere else, but I can't see why they wouldn't work.
Thanks!
Not speaking Norwegian I'm not sure exactly what it says, but I already have Radio version 4.08 so I'm not going to change that. Is there a list of the problems that this release fixes that you know of? (There isn't one in the zip file) I'm specifically interested in fixes to the Communication Manager and GPRS connection handling and I don't know whether these would be in the BIOS upgrade or the Radio upgrade. I know that various people have Radio v6.x and ideally i'd like to get hold of this.
Any help you can give is much appreciated,
nick.
4.08 is actually way older than 3.19 (v8 compared to v19). From what I've read on this site, the first digit in the version number is sort of an area code that will differ between different areas rather than different versions. I am not sure the 3.XX would work for you as your original is 4.XX, but I think there has been a discussion about that in another thread.
What it tells you on the Norweigan page is more or less that you have to make the upgrades in the correct order, or they will fail and leave you with a non-working device.
I think the improvements you're looking for are in the radio upgrade, but for a stable device you should probably upgrade both at the same time.
I've also heard that in the UK, the O2 version of the radio stack has been 'optimised' (a moot point, since it doesn't currently work that well) for use over the O2 GPRS network, so I'm thinking it might be wise to wait for the official 4.x release. Unfortunately they're being slow in producing the update and we've got customers complaining about the reliability of the connectivity in our software when it's all down to the flaky radio stack (!)
Thanks for your help,
nick.
Just to update everyone: it was a problem with the radio stack not allocating resource for the return leg.
The problem went away when I installed radio stack 4.20.
MikeS.
GPRS has an issue. The downlink is kept alive by sending packets in hte uplink, and vice versa. So if you are sending downlink UDP data with nothing on the uplink then the GPRS downlink will timeout after 62 seconds.
So if you are coding a video or audio streaming application please send an uplink packet now and then...
(Pay attention Microsoft WMP team)
try this program:
https://www.handango.com/PlatformPr...og=30&txtSearch=gprs§ionId=0&platformId=2
GPRS socket
Could anyone send me a sample code creating and using socket over GPRS ??
I ve only found how to send HTP request over GPRS in the forum.
I d like to be able to send packets in UDP for a VoIP softphone.
THANK YOU FOR YOUR HELP
Hi,
I need to read CellID and RxLev by my program. I have no idea how to do this. Could anyone to help me? Thanks
Unfortunately it's not been implemented by HTC, so the simple answer is no. You could try and use the SMS system directly through RIL, although because Cell based positioning is quite a hot topic and nobody has yet done it, I'd guess it't not possible.
Anybody know if XDAII has a working API for this?
Just use tracelogger, pwd is htc, choose MMI + Event then run the tracelogviewer provided by the XDA developers site you'll get your CID and rx Level
andyclap said:
Unfortunately it's not been implemented by HTC, so the simple answer is no.
Click to expand...
Click to collapse
This is I would guess why RIL_GetCellTowerInfo always returns 0x80004001, which I belive means not implemented. (XDA I) But I might be using the wrong call... ??
If this information is available on the XDA II, then there must be programmatically a way through RIL, so either I am using the wrong call, or RIL has been fixed, or something else I haven't thought of... Any ideas?
Ben.
Yeah, it would be great if the XDAII supported this (Cell based min-GPS!), so does anybody know for definite the scope of the new RIL on the XDAII?
andyclap said:
Cell based min-GPS
Click to expand...
Click to collapse
You read my mind!
I think this might be why this information is so hard to find. This data, once calibrated (which using, say, TomTom, would not be hard) is a considerable asset, to which the various phone companies are trying to protect. Which sounds like a challange to me...
Ben
Yeah - O2 at least are marketing this info as a developer program, with a lookup charge "from 5p per lookup". What a bargain, considering the device already has the information (though it really applies to mobile phones that don't have SDK access).
Don't they realise that if they helped us create an app for them to do this and, say, link to multimap.com, it'd be a killer app and they'd sell hundreds more XDAs.
Good idea. They would get the GPRS service charge for the multimap lookup as well. Although I think the cell id is too course. But some part of the phone knows far more accuratelly where it is, so that it knows when to change cell. Although this is not yet an area I know much about.
I belive, if you jump through enough hoops, O2 gives grants for programms which enhance the XDA, there's a project for somebody.... If anybody can work out how to get the s***ding cell id out of the XDA
ben
Yeah - O2 at least are marketing this info as a developer program, with a lookup charge "from 5p per lookup". What a bargain, considering the device already has the information (though it really applies to mobile phones that don't have SDK access).
Don't they realise that if they helped us create an app for them to do this and, say, link to multimap.com, it'd be a killer app and they'd sell hundreds more XDAs.
Click to expand...
Click to collapse
The idea of the Location APi is not as good as what we want. The idea is that an office queries O2 servers for the cell location of the target unit, for which they charge the office (end-user). O2 are looking for software solutions that draw on this to provide added content so that some poor sap carries on paying 5p a hit to get back the rough cell based location of a unit. Bloody expensive as a tracker or SatNav. Might as well just stick a GPS unit on the back & send that data back via GPRS - cheaper!
O2 actually have a website with the info on their cell sites on it BUT they have 8500 of them at least, so getting all that info out is a hard task.
Site is Here
We need to crack getting Cell ID, Signal Strength, Nearest Other Towers, Nearest OT Signal Strength + I daresay a few more before applying that to a database, after which we could probably have a device that told us our position to within 100m, which we could then send back via GPRS, thus not allowing the network to charge 5p a hit.
That's why the Cell Location database is not available - they stand to make/lose too much revenue.
Wonder how much the database is worth?
It wouldn't be too difficult to scrape the site - while it gives no true positional information, it can return a list of cell towers within a radius (upto 5km ish) of a known tower, with their distance: we could triangulate three sets of this information to get the real locations of towers. Once these locations are known, we can recursively triangulate from them to eventually get all the data for the UK at least.
But, the main thing to do, as you say, is to find a programmatic way of getting the current cellId, signal strength, and preferably as much information about other local towers too to further refine the result.
Hmmm, just thought - as the XDA developers here are "jolly nice and clever people", they have supplied the source to tracelogview. It wouldn't be too difficult to modify this to scan for tower information messages and do the appropriate things. It just means that the users have to enable tracelog manually, though perhaps we could send some keyboard messages to start it up and enter the password. It's hacky, but it just might work!
Might have a go at this tomorrow!
Overview of Location APi as offered by O2 - taken from Source02 website
The first of our APIs to be delivered is the Location API which has been developed by our partner Redknee.
The service enables you to create and sell innovative new applications and services based on a mobile phone user's location.
The O2 service is charged from 5p a lookup and provides the longitude and latitude co-ordinates of the centre of the cell site sector the phone is located within. Cell sites are typically split into three sectors and range in size from several hundred metres in urban areas up to 15 kilometres in more remote regions.
Third parties are able to develop location-enabled applications utilising real time location data from the O2 UK network. Application owners will have the opportunity to validate their applications in a test environment prior to connecting to the live O2 UK network. Location information will only be passed to third parties who have a contract with O2 and have the consent of the end user to determine his/her location.
Click to expand...
Click to collapse
I may be wrong, but...
I belive the telco and the phone have a different idea of where the device is, as they plot the position of the device using different mechanisms and for different uses. They use this when they have to contact a phone to send an incomming call. This application is making use of the telco's permanent database of the location of all their devices. This is easy money for the telco.
We do not have access to this data, and the positional information we can get will be in a different format, accept for the Cell ID. We will have to infer the position of the XDA from RIL, TAPI, AT, using the data listed in previous postings. As was suggested, getting an idea of the strength of local transmitters, and calculating a position. Which in it's self may be a real challange, as there is not likelly to be a linear relationship between the strength of the transmitter and the distance to it.
It may be likelly that the cell size (~200m, -> ~15km) is the nearest we'll ever get. I note that people in Dover very often get routed through transmitters in France due to the cliffs on the coast of England. In this case, any meaningful positional data is getting more unlikelly.
PS, can any kind person with an XDAII tell me whether the RILL call:
HRESULT RIL_GetCellTowerInfo(HRIL hRil);
Returns something other than 80004001?
Ben
PS, can any kind person with an XDAII tell me whether the RILL call:
HRESULT RIL_GetCellTowerInfo(HRIL hRil);
Returns something other than 80004001?
Click to expand...
Click to collapse
Unfortunatelly this still returns '80004001 Unsupported' on XDA II.
But the RIL_GetSignalQuality does return valid data when connected to GPRS, unlike XDA I, so some things are getting better...
Ben
Hi all,
i just saw a programm that uses the cell ID and convert this one °, but it just works with received data from any handy via Irda or cable.
So if u want to take a look visit (german site):
http://www.wolfgang-back.com/navigauss.php
That works but it would be the first way, to use the XDA cellID instead of external data...perhaps any idea on this?
With greetings from germany
Harry
Cell ID
Guys u can get the cell id using java.
The cell ID is memorized in the sim card and the mobile phone compares always whether the CID he is receiving from the signal, is the same one memorized in the sim card.
If yes the mobile does nothing. If not the mobile phone updates the CID in the sim card. this is done almost every 5 seconds.
Now we need the API !!! and maybe the AID of the sim applet. :roll:
Once more,
could the following be a walkable way?:
1. cell-Id could be shown (tracelog and traceview says how)
2. If that is fact, then it is with calculating gauss-to- longitude/latidude (visit www.nobbi.com) makable to view the actually position.
3. The last step it would be, to bring Information like longitude/latidude in ° to the standard gps-format (it is known or free i think) and send it via comm1 to all navigation-software.
4. So if this all is nonsens tell me because i am not really a programmer ( my code would be as fine as my english is :-((
bye Harry
Hiwi said:
1. cell-Id could be shown (tracelog and traceview says how)
Click to expand...
Click to collapse
That's right, but cell id says nothing about position.
2. If that is fact, then it is with calculating gauss-to- longitude/latidude (visit www.nobbi.com) makable to view the actually position.
Click to expand...
Click to collapse
see comment 1. Only O2 Germany transmits GK/coordinates over Cell Broadcast....
3. The last step it would be, to bring Information like longitude/latidude in ° to the standard gps-format (it is known or free i think) and send it via comm1 to all navigation-software.
Click to expand...
Click to collapse
If 1. and 2. would be possible this is still a problem since most (all) GPS-Software only accept input from COM-Port (you have to emulate a COM-Port ... not trivial)
4. So if this all is nonsens tell me because i am not really a programmer ( my code would be as fine as my english is :-((
Click to expand...
Click to collapse
:wink:
John
Having written a DLL to get the CellID from the XDA, and then comparing the result with the O2 cell tower map info as described by 'Puff the Magic Wagon' on Nov 4, I find there is a discrepancy of 10000
e.g. in a clients office in Blackburn
Cell ID returned = 3AAF( Hex) = 15023 (Dec)
From www.webmap.o2.co.uk Higher Audley Cell = 5023
This seems to be the case for all cells I have tried.
There also seems to be some Cell ID's which I cannot reconcile with the o2 map results.
mjgermain
The problem you've encountered arrises from the fact that there are more than 9999 CSR (Cell Site References) that are registered with the RA.
O2 identify cells in the following way.
AXXXX
Where A = the direction the transmitter is facing (directional transmitters)
(roughly)
1=North
2=South East
3=West
then 4, 5, 6 & sometimes 7, 8, 9 depending on how many transmitters on the aerial - always in 3s
So in your example 1XXXX, the transmitter is facing north (so should be to the south of you) but depending on that aerial (yours only has 3)
We then get to the XXXX
I believe that CSRs are allocated by the government and are a 5 figure number. Therefore CSRs upto 9999 are able to be placed quite simply.
15023 is correct.
However, what happens when transmitter number 10001 comes along? According to O2 numbering system, that 0001 number is already allocated. So they have to use another method of identifying cells.
Somewhere else in the country there might be transmitter that IDs as 15023 :shock: :?
So having a database of CellIDs and transmitter numbers is not all that is needed, the additional "identifier" is required and together that gives the CSR which has a lat/long applied to it.
The identifier is the LAC or Local Area Code
So AXXXX + LAC = CSR
There are still a few anomolies in this as well it would seem. Fill-in transmitters and "private" or "mini" transmitters the likely cause.
I had access to the O2 CellID db when I was last working & we were able to create a basic Cell tracking system, but the company went titsup.com before we were able to factor in LAC and signal strength etc.
Does your program work on XDA2?
I am particularly interested in the wizard, however on a fundamental level WM will most likely operate the same across most models in respect to this issue (or at least that is the theory).
I realize that most GSM boards have processors on them which do things like channel syncing (which is fairly time sensitive since its tdma&fdma), a5, gsm framing, and all that. You more or less connect a sim, speaker and mic, and treat the gsm rf board as a black box.
I am hoping that somewhere someone has unearthed something that allows more direct control over the gsm board on these phones. I am aware of engineering mode, however that is not quite what I wanted.
I would like to be able to at the very least set the call parameters before a call goes out. For example, lets say that I want to disable A5, sinec there are 3 standard levels one being no encryption, and the tower and the phone negotiate and agree upon the highest common, something in the phone somewhere has to say that it supports encryption.
I am just uncertain if all that is burried away in a 'black box' somewhere and its not a software problem from within WM.
If anyone has any ideas I would greatly appreciate it, even if they are pointers to research material that may help me out a bit.
On WinMobile GSM part is isolated from the windows part, like in normal PCs modem hardware is isolated from mainboard. GSM part has its own CPU, RAM, ROM, operating system, and communicates with Windows via COM-port (or USB port in Universal). For example Universal has Qualcomm MSM6250 chip with some proprietary OS. HTC Himalaya had a different chip (I don't remember it now), and OS was based on nucleus RTOS. Anextek SP200 communicator had Siemens MC45 modem inside.
GSM hardware is a black box for WinMobile OS. MS specifies only some recomendations for OEMs, and controlling encryption is not among them. You can control it if GSM vendor supports some AT command, or some other proprietary method (maybe via dev_specific RIL command).
In the case of Universal, its GSM can be controlled from a PC with the usual Qualcomm diagnostic software (QXDM, QPST, etc), when you setup the device as a pass-through bridge between PC and GSM module. But I don't know any methods of doing the same from inside WinMobile.
mamaich said:
GSM hardware is a black box for WinMobile OS.
...
You can control it if GSM vendor supports some AT command, or some other proprietary method (maybe via dev_specific RIL command).
In the case of Universal, its GSM can be controlled from a PC with the usual Qualcomm diagnostic software (QXDM, QPST, etc), when you setup the device as a pass-through bridge between PC and GSM module. But I don't know any methods of doing the same from inside WinMobile.
Click to expand...
Click to collapse
That is what I was afraid of. Most of the GSM radio boards (or individual chips) are set up to act that way, and since its faster and cheaper I really dont know of anyone that hasnt done that in any phone that was made in the last few years.
At any rate, is there any documentation that discusses how to locate which com port or other method is used to access the GSM device within a wizard (or any other htc model, odds are many of them are similar, if not identical with this subcomponent).
Are there any known AT commands? my first project is to write something similar to the gsm engineer mode program, obtaining BTS information. I am unsure if this is obtained only via AT commands or if its something more involved, but welcome any information on this.
Found what appears the be half the answer at http://wiki.xda-developers.com/index.php?pagename=RIL While that gives me access to the radio for some stuff (location data app that can work with gsmloc.org for example) it does not appear to enable me to set any parameters for a new call.
So if anyone knows of any tricks that would help say for example disable a5 crypto (on a per call basis idealy) or something similar to the setup of a call I would still appreciate hearing about that.
I know that Typhoon ( spv c500 / i-mate sp3 /Dopod 565) memory block with gsm info data. I am trying to find it in Magican - but no results. I dont know how Typhoon place this info in mem.
I have a problem with a Windows-Mobile 6.5 Device and my c# .NET CF 3.5 software.
I developed a POS-Software which worked quite fine, but since the newest firmware upgrade I randomly get HTTP500 errors when I "POST" a request to my REST-Server. (Only when connected via GPRS)
The Problem with that: They are not from my server, because they have a different content and they don't appear in the server logs.
Could it be, that the HTTP-Errors come from my network provider who is maybe proxying my requests?
The InternetExplorer seems to work fine.
Has anybody an idea where the HTTP500 errors could come from?
Having been working at a telco I can confirm that all traffic goes through their routers/servers. It's actually logical if You think about that they have to charge You for the traffic, so they must count the bytes. The fact that it only occurs when connected via GPRS and the fact that it's not from Your own server pretty much confirms it. But... I am suspecting that the latest firmware that You refer to has something to do with it. By firmware You mean ROM I guess. Maybe there is a flaw related to protocol handling in the ROM, have You tried with other ROMs as well? If You haven't, test it. It could also be a faulty ROM instead telco problem. Or it could be both. Anyway it's easier to test a different ROM than to get an able technical person on the line from Your service provider, who would be willing to dig through the massive logs of the telco servers and in the end declare that they can't do anything about it. That's the bottom line in 99,99% of the cases.
My 2 cents.