btw, I was looking my hcidumpfiles and I noticed that all attributes are separated by hex 0d 0a (like new line), but there is no separator between END:VCARD and BEGIN:VCARD. Is this a bug? This could lead to a situation where vcard boundaries are not detected and only buffer size would limit detection. This could result the situation I am seeing.

Eg the output is now something like this

BEGIN:VCARD
VERSION:2.1
TEL;CELL;VOICE:+358501589
N:Rosenqvist;Jarmo;;;
FN:Rosenqvist Jarmo
END:VCARDBEGIN:VCARD
VERSION:2.1
TEL;CELL;VOICE:+358501872984
N:Viskari;Esko;;;
FN:Viskari Esko
END:VCARD

To my mind it should be

BEGIN:VCARD
VERSION:2.1
TEL;CELL;VOICE:+358501589
N:Rosenqvist;Jarmo;;;
FN:Rosenqvist Jarmo
END:VCARD
BEGIN:VCARD
VERSION:2.1
TEL;CELL;VOICE:+358501872984
N:Viskari;Esko;;;
FN:Viskari Esko
END:VCARD

What do you think?

this is *OLD* news

n900 cant sync over BT

nothing to see here, move along please

We know were working on fixing it... so you best move along....

Jarmo, few days ago when I checked your HCI dumps I watched those too. I tried to find some sort of information about it but I didn't find anything else than Microsoft Navready's documentation, which might be valid for other PBAP implementations too. It says for example that:

A vCard is considered valid if all the following are true:

1.It contains at least one phone number with 2 or more digits.

2.Each line is exited only by using a carriage return and line feed (CRLF) character.

3.The character set used is either ASCII, UTF-8, or ISO 8859-1.

4.The vCard size does not exceed 400 KB.

5.If an encoding other than quoted-printable or 8-bit is not used.

****
So the current maemo implementation might work with some car kits, but some (like BMW) might be little picky about the format and CRLF character is needed to make it operational. It is easy to try thou...

Jarmo/Loukkis:

Looked at the vcard plugin, and it is definitely missing any kind of CR or LF or anything at all to break two vcards apart. I put together a few binaries that I'll test momentarily to see if they still work here. If they do, I'll post the different HCIDUMPs and get the binaries to you guys.

browncaravan:

It looks like your installation of openobex 1.5 might have failed because of the mp-fremantle-205-pr package. If you remove it, apt should stop complaining about unmet dependencies (and stop the erroneous "update" notification). This may be a step that I completed, but forgot about. Let me know if it fixes the problem...If you still want to downgrade, try enabling the extras repo.

garyc:

It may be old news that it can't be done, but the *NEW* news is that it can. Perhaps reading through the thread, rather than dismissing it out-of-hand, would be more beneficial to you...especially if you are some one who wants PBAP to be available and work...



Drew

Silly question, but is your internet connection active while trying? It should be...

Hi Guys!

First of all THANKS A LOT for your efforts to make this work GREAT JOB!

I followed the instructions from drdrewusaf's legendary post #70 and tested with my 2008 (Facelifted) 3series BMW.

It was PARTIALLY SUCCESSFUL:
After the required outgoing call and a few seconds some contacts were transfered, but unfortunately by far not all of my contacts (between 20 and 30 out of 300+ contacts).

Looking at the transferred contacts it seems that there is indeed a problem with the transfered vCards format, as the entries are incomplete (entries with only name but no numbers/details, entries with missing details or cut off address entries).

Interestingly my N900 shows my car still as device type "Free Hand" and with supported profiles "HFP" and "OPP" only...

Guess I will wait for the already announced OBEX update before further testing...!?

BTW: File transfer between PC and N900 still works in both directions for me.



####
EDIT:
Get the same Maemo5 update mentioned before.
Missing packages:
obexd (= 0.18-0maemo5+om5)
libopenobex1(=1.4-0maemo3+0m5)

drdrewusaf, did I get you right? Does that mean my installation of openobex 1.5 failed???

What is mp-fremantle-205-pr package and what trouble can removal thereof cause?

Wow, what's the deal w/ BMW? How are three cars around the same model year getting three different results? Does BMW really change their hardware that often?

Anyway below is a link to the 0.29 OBEXD binaries. I found that the MeeGo developers are using the "tracker" back-end as default, but I'm not sure why. In any case, just for this round of builds, I compiled both an "ebook" and "tracker" version. From now on, however, unless specifically requested, I will only be building the "ebook" versions (the "tracker" version did NOT work w/ my head unit).

Link: http://www.mediafire.com/?sharekey=f...953e47d6c516bd

As far as this Maemo update and unmet dependency business goes, it is VERY likely that the installation of the new openobex package was not completed...at what point of the installation this happens, I don't know. I also don't know if it causes any other issues (the people reporting the problem seem to be getting results, which means openobex working well enough to get PBAP up and running). The mp-fremantle-205-pr package appears to be a dummy package that describes ALL of Fremantle. The removal of this package MIGHT cause headaches down the road when PR1.3/4/2.0/whatever comes out (or any distribution upgrade for that matter). In any case, re-installation of that dummy package and the removal of openobex1.5 would fix the problem... I just checked on my phone and I HAVE removed mp-fremantle-205-pr (like I said before, I probably forgot to document it). I have not run into any issues regarding that package yet.

Finally, I haven't had any success with the CRLF binaries yet, they refuse to transmit the phone book altogether...




Drew

I guess that in the end Reflektorfalke's and my results are the same. If the problem is in the layout of the vcard the results could be just like that.

Current obexd also sends contacts without telephone numbers and even vcards without any name. I don't know what the car kit thinks about them.

I must try to change the addressbook just a little bit and look what kind of a change it makes to the car kit parsed data. If vcard boundaries are not detected and the whole buffer is just read like a one vcard there should be changes only to the names which occur after the change and changes should be random.

This is getting interesting.

Please forgive me Drew I'm a noob but how can I use those 2 files from your link (I unsuccessfully tried the app manager...)?