Related
I'm developing, for XDAII and in eVC4/Win32, an application that opens a serial port for incoming Bluetooth. The Bluetooth Manager sets COM4 as active port number, but my call:
CreateFile(TEXT("COM4:"),GENERIC_READ | GENERIC_WRITE,0,NULL,OPEN_EXISTING,0,NULL);
fails with error message "The specified network resource or device is no longer available".
When I then try to call:
RegisterDevice(TEXT("COM"),4,TEXT("ASIC5_BTUR.Dll"),0))
also this call fails.
What am I doing wrong ? When I look in the Register [HKEY_LOCAL_MACHINE\Drivers\Active] I find no COM4 active so there is no obvious reason why this call should not work. Have the BTHTools1100 patch installed !
Hello, I am experiencing similiar problems. Have you resolved yours ? If yes, could you show me how you open your ports etc.?
read this :
http://forum.xda-developers.com/viewtopic.php?t=1263&highlight=
I am not sure how your link to COM1 prolems regaqrding signals sould help me. My problems are with opening Bluetooth SPP ports, those that show up as the Inbound and Outbound COM ports.Though I would think that both are active, üsing CreateFile() I can open only the Incoming one (COM4) while I receive an INVALID_HANDLE_VALUE for the other one (COM5).
I just saw some info on com ports being inactive as well as a test program so I thought I'd mention it. Didn't mean to provide a solution, sorry
I tried to get the Bluetooth working and also had trouble. I think the inbound and outbound comm ports is to do with if you are using your SPP device as a client or server. It is not as a lot of people think that TX and RX data are on different Comm ports.
I cound not get Bluetooth working at all using my original XDAII rom of 1.60. I downloaded Pocket Bluetooth Tools http://www.bluetooth.jazztel.es/ and then it worked easy on Comm7.
I recently upgraded my XDAII Rom to 1.72 and I tried the Bluetooth support again. This time the XDAII even said I am connecting to a serial SPP device and automatically allocated the Comm port. But I must say my program could still not transfer data correctly using it. It all got stuck in some initilisation sequence. Now that may of been my software so I don't want to blame the XDAII.
All I know is I installed Pocket Bluetooth tools again onto my 1.72 XDAII and all worked fine again on Comm7.
A friend of mine has a new XDAIIs and the inbuilt bluetooth support on that worked 100% first time, no need for the Pocket Bluetooth Tools on that. So I think the problem is with the XDAII and it's built in SPP support.
Had the same problem, resolved it:
Strange but true, but on XDA2 etc, in order to receive COM Bluetooth, you have to open the outgoing port as shown in the Systems Bluetooth settings (You have to tick it there, too, of course), not the incoming.
Then, as it is blocking, you have to create a thread that listens on the port.
You cannot use RegisterDevice for a port number (in your case COM4)that is already used and open.
Phil
OOPS.... and you have to call OpenFile(), not CreateFile() !!!!!!!!!!!
Trying to write a program to record phone calls and act as answering machine. I'm initializing TAPI, opening the cellular line, then trying to use lineGetID to get the "wave/in" and "wave/out" devices id's, this last function call always returns the same error "the operation failed".
Any thoughts???
as I've wrote before it is impossible to make an answering machine. You can record phone calls, but cannot play anything to the line. It is a software limitation in CE 4.20
HOW can you record phone calls
(sounds handy when certain callcentre agents make promises)
built-in recorder can record calls. You may decompile it to find how it is working. I think that code used to record calls is the same as recording from a device microphone when the call is not active.
How would you use LineGetId in order to recieve data calls through TAPI ?? I'm struggling udnerstanding where this function should be implemented and what it actually does.
Thanks for all your help !!!
After you catch CONNECT event (media type is datamodem) you must get handler of opened serial device for data transmition
1)LPVARSTRING lpVarStr;
2)Allocate memory for lpVarStr;
3)Call lineGetID
for example: lineGetID(0, 0, hCall, LINECALLSELECT_CALL, lpVarStr, TEXT("comm/datamodem"))
4-th parameter means how call will be selected
LINECALLSELECT_CALL - select by specified call
also you can select by deviceID, address, line etc
last parameter specifies device class (look msdn for possible values)
4)check lpVarStr->dwNeededSize
5)Realloc lpVarStr
6)call lineGetID
7)get handle of serial device *(LPHANDLE)((BYTE*)lpVarStr + lpVarStr->dwStringOffset))
I think you will find that the ability to record the incoming audio is only as a result of the microphone picking up the audio from the speaker. I have tested everything I can think of to do this and hit a brick wall. firstly if you check the linedevcaps for each line device, non support the "wave/***" classes needed. Secondly the linegetid will always fail because of the way the line is being opened. To open a line correctly to use "wave/***" in linegetid, the dwmediamodes flag of lineopen needs to be set to LINEMEDIAMODE_AUTOMATEDVOICE. If you did not an error of LINEERR_INVALMEDIAMODE returns. If your error is LINEERR_OPERATIONFAILED, I think it could be coming from your timing of when you call linegetid. This will not work on any device I have because the hardware will not support it.
There is a physical seperation between the hardware that picks up and sends voice, and the computing hardware. I first encountered this while using an audiovox rtm8000 card in a toshiba e570. The modem built into the card can communicate data over the port but dose nothing with audio. That may sound irrelivant exept that later audiovox started selling the hardware combination built together under their brand as a pda phone to compeat with xda. They modified it by hooking the system speaker and mic up to the card with extra wires internally. All pda phones are arranged essentially like this. the fact that you cant see a seperate "phone card" makes it deceptive.
.
.
.
.
.
loose end. How dose my bluetooth wireless earpeice get the audio from my xdaII. Explore that, I am.
Hi all,
On the phone parameters menu, there is a tab named TTY. Do you know what is it? Because the French translation is not great ...
Thanks!
It is the same in the english version. I don't know what is it for.
[ ] Enable TTY support
Attention: Enabling TTY support may decrease the quality of voice calls through a wired headset.
Have you looked if there's any info about this in the manual? I don't have it with me right now.
Neither do I...
We definitely need a PDF version of the manual
I could be wrong, but isn't TTY a technology for assisting the deaf/hard-of-hearing?
It can refer to the text phones or 'minicom' that are used by deaf people.
If the TyTN can make calls straight to landline minicom's, that would be great!
Did anyone look in their manual?
If not - I will try calling my minicom with it next week when I get mine... can't wait
snalbansed said:
It can refer to the text phones or 'minicom' that are used by deaf people.
If the TyTN can make calls straight to landline minicom's, that would be great!
Click to expand...
Click to collapse
Exactly correct! The TTY or Minicom (UK version) service uses an old 5-bit Baudot coding rather than ASCII or Unicode; this would allow messaging to / from TTY units.
Just a case where the needs of the disabled community have again been recognized!
I'm afraid gpstoloff might be rejoicing too soon
When I got my TyTN, I tried to enable TTY. Doing so just creates the message: Unable to change TTY mode. Please try again.
I contacted HTC User support, which produced the following response:
Dear Sir
The option of TTY will allow you to connect the TyTN to a TTY compatable device for use. You will not be able to enable TTY support until the TTY device is connected.
Click to expand...
Click to collapse
I replied to ask what TTY compatable devices existed, and what they were. I then got the following email:
Dear Sir
At present we do not have a list of TTY compatable devices, but I will look into this and request information from out technical team. Once I have some information I will contact you.
Click to expand...
Click to collapse
I shall wait and see... :?
I suspect it is to enable a TTY to be linked to the mobile phone to make normal TTY calls, where there is no landline. I have a TTY that can do that, but whether it's compatible with the HTC is another matter (it will work with my Nokia 6310i) and you can usually get the appropriate data cable from the TTY manufacturers. Not all TTY can work with GSM phones.
I also have a Nokia 9210i which can make TTY calls direct as it has TTY software onboard. TTY software on the HTC would be a better option than a plugged in TTY in my view.
What is a TTY?
TTY stands for Text Telephone. It is also sometimes called a TDD, or Telecommunication Device for the Deaf. TTY is the more widely accepted term, however, as TTYs are used by many people, not just people who are deaf.
A TTY is a special device that lets people who are deaf, hard of hearing, or speech-impaired use the telephone to communicate, by allowing them to type messages back and forth to one another instead of talking and listening. A TTY is required at both ends of the conversation in order to communicate.
To use a TTY, you set a telephone handset onto special acoustic cups built into the TTY (some TTY models can be plugged directly into a telephone line). Then, type the message you want to send on the TTY's keyboard. As you type, the message is sent over the phone line, just like your voice would be sent over the phone line if you talked. You can read the other person's response on the TTY's text display.
If you don't have a TTY, you can still call a person who is deaf, hard of hearing, or speech-impaired by using the Telecommunications Relay Service (TRS). With TRS, a special operator types whatever you say so that the person you are calling can read your words on his or her TTY display. He or she will type back a response, which the TRS operator will read aloud for you to hear over the phone. Toll free TRS services are available 24 hours a day, 365 days a year.
You can visit the Ultratec website for information about a wide range of TTYs for home, office and personal use. Or, visit these great online stores for all your assistive device needs.
Yuri_su
Stockholm, August 21st 2006.
Dear Forum:
In searching for an answer why the transfer of data over a SPP bluetooth link from a scanner to a Smartphone (OS=MS Smartphone 2003) I came across the below forum entry, which I would like to ask you to comment on.
We have a C++ application running on the Qtek's developed in Visual Studio, using the scanner manufacturer's driver libraries, and many times we experience a difficulty already in the pairing of the two devices.
Secondly, the data transfer (a barcode of a few bytes) between these two devices seems to persistently take seconds, whereas the upload and subsequent ascii-code reply over GPRS from the server to display the validated data is much quicker once that data channel is up.
Where do we start the troubleshooting, and what can you perhaps say re. the BT stack problem here below? Probably the "timeout" it speaks of should really be referred to by some other term, no?
Looking forward to your analysis, AND please alert me by email of any blog/forum response!
Brgds,
/Per Hagman
===============================================
"I was not sure if the slowing part was the phone or the "Bluetooth to RS232" dongle.
So I wrote a test application that sends a char over ther serial port and measure the time it takes to get a echo response.
When I use a serial cable between PC and my Qtek 8080 (HTC) I got 10 ms in response time. Thats OK.
So changed to bluetooth connection.
The response time was now 1002 ms!!
I removed the "Bluetooth to RS232" dongle and connected a TECOM "Bluetooth to USB" dongle at the PC side. The TECOM use WIDCOMM 1.4210 bluetooth stack.
The responce this time was 1003 ms.
The Qtek 8080 (HTC Voyager) has microsoft bluetooth stack inside.
A conclusion of this is that the microsoft bluetooth stack has some kind of timeout that is set to 1000 ms.
It takes some time to pack/unpack data on the bluetooth link, but it should not take 1000 ms to do this.
Wonder if there is some way to change this timeout??
Honken"
URL= http://franson.com/forum/post.asp?method=ReplyQuote&REPLY_ID=359&TOPIC_ID=163&FORUM_ID=3
This process sounds good for what I need to do.
I need to connect and pair up a bluetooth device(being the bluetooth cradle) in which the gps connects to for it to recieve the satellites.
But I dont know the password so I need to pair and connect the devices without using the password?
So how do I do this
There should have an instruction on how to connect your GPS unit (bluetooth) with other devices (e.g. button to press etc and the password to use, e.g. 0000 or 1234). Read the manual.
Yes I do not have the manuals I brought 4 prophits with the gps receivers of a company and I do not have the password to connect/pair them up so I need somebody to tell me how to bluetooth hack(or something of the sort) to make a connection with them/pair them to use the gps
First of all, it is technically difficult to get the password of a bluetooth connection without the device making connections and transfering data. If I'm not mistaken, getting the 'password' out of a bluetooth connection, you will need the device to be sending signal among each other. While enough package (data) have been captured, you can then 'guess' the pin out of the large quantity of data. That is possible if you have the appropriate hardware (not your phone) and software.
Secondly, as the bluetooth device is paired (or worse still, un-paired) to another device, you need intensive hack to your phone to spoof as the bluetooth that it is not (e.g. trying to pretend to be another bluetooth device), which I'm not sure is feasibly do-able (if not impossible).
Finally, as I've mentioned above, rather than spending time on trying to do the near impossible, try to look for this manual. And, there shoudnt be that many buttons on the GPS unit that, with a certain amount of trial and error, you ought to be able to make it into pairing mode and try guessing the PIN from there. The default PIN for such `unnecessary to be secure` device are usually the commons one like 1234, 1111, and 0000.
Yes But I brought them without the manual. The make is Mercury but can find any information about them on the internet and ive tried all the normal codes such as 0000, 1111, 1234, 1166, 1616, 6611 etc
attitude said:
Yes But I brought them without the manual. The make is Mercury but can find any information about them on the internet and ive tried all the normal codes such as 0000, 1111, 1234, 1166, 1616, 6611 etc
Click to expand...
Click to collapse
tried 4321?