Quick-Jack iOS receive errors

[lpcware]

Content originally posted in LPCWare by [email protected] on Tue Oct 21 10:39:30 MST 2014
Has anyone in the forum noticed byte transfer errors in the Quick-Jack iOS application?

I am attempting to transmit less than 200 bytes in serial order from point to point (ie: LPC812 -> iOS) but not all the bytes make it across. Xcode debug output is indicating errors in reception of some of the bytes (ie: diff too long xx messages).

Interestingly, the errors are only showing up when running the Quick-Jack app on my iPod Touch (5th Gen) but not on my iPhone 4. Both have iOS 7.1.2 installed.

If the receiver is not reliable across models then I'll have to build a transfer error checking and resend mechanism.

Any comment on this is welcome:)

[lpcware]

Content originally posted in LPCWare by Allen_Tang on Tue Jul 14 21:54:23 MST 2015
Hi All,

Have any one successfully downloaded the APP from the iOS App store?

I tried to search the NXP Quick-Jack, found nothing.

Thanks
Allen

[lpcware]

Content originally posted in LPCWare by [email protected] on Tue Mar 31 18:11:46 MST 2015
I'm glad someone out there other than me has noticed this :)

I never tested an iPod Touch 4th Gen so it's new information to me that this gen works. Finding the problem is easier this way starting from something working.

No, I did not find the root cause on the 5th Gen as my project does not include iPod as a requirement.

Would love to know if you find the solution though. Good luck!

[lpcware]

Content originally posted in LPCWare by glucas on Fri Mar 27 07:16:42 MST 2015
I am seeing the same exact issues you describe moving from an ipod touch 4th gen to an ipod touch 5th gen.

Did you ever find a solution?

[lpcware]

Content originally posted in LPCWare by [email protected] on Thu Nov 13 16:23:30 MST 2014
Thank you for the reply and suggestions :)

Yes, using a checksum and retry mechanism will be needed to account for byte transfer errors and I do intend to write one for this application. However, I cannot explain the dramatic increase in errors when moving from one iDevice to another all other things remaining the same. A 1 out of 5 or 10 byte error rate on some devices will make transfers inefficient so it's good to know this in advance.

Q1: Has the NXP development team observed similar errors in their own testing?
Q2: What iOS version/iDevice hardware combinations has the NXP team tested with Quick-Jack?

I modified one of my Quick-Jack boards to use a 12MHz Xtal on the already present footprints. The LPC812 code also needed small modifications to use the xtal as the clock source instead of IRC. The increased error rate on both iPodTouch5g and iPhone 5 is still present. Note that the iPhone 5 (Model A1428) I tested is running iOS7.0.4. The iPhone 5 yeilds 'diff too long' errors for all Joystick codes not just 0x04 and 0x02.

So far the IPhone 4 + iOS 7.1.2 is the only combination tested with a low error rate.

Q3: Would changing the baud rate from 1.4Kbaud to something else make a difference?
Q4: What code modifications are needed to change baud rate?

Our application requires self powered operation and bidirectional communications for board<->iDevice. Data is 'dumped' from one device to the other but does not happen at the same time.

[lpcware]

Content originally posted in LPCWare by Magicoe.Niu on Wed Nov 05 00:59:35 MST 2014
Hi,

I feel you can added checksum function and re-transfer function to skip this. Infact, every serial without clock reference exist transfer bit error.

Quick-Jack board use crystal less mode, IRC accuracy is 1%~1.5%, if transfer data length a little long, the error rate will growing up.

If u want use more accuracy transfer, pls use external crystal that should more reliable.

Pls also added some correct data singal function, that would let your transfer more reliable

If u do not need self-power function, you can also use a output channel as clock singal and other output channel as data channel.

Thanks!

[lpcware]

Content originally posted in LPCWare by [email protected] on Tue Oct 28 13:16:36 MST 2014
Some additional notes and observations:

1) I've confirmed that the Quick-Jack board P14 and MIC signals being transmitted from board->phone are identical when plugged into iPhone 4 or iPodTouch5g.

2) I’ve tried to adjust the MIC output channel R1 resistor to a lower impedance (2K2) as recommended in Section 8.2.1 of AN11552_1_0 for Apple devices but does not improve things (actually makes it worse). All tests were performed using R1=100K as is default.

3) I've confirmed that the iOS sampline rate on Both devices is 44100 via inspection of hwSampleRate variable. I`ve read in other posts that this can be different among iDevices.

4) iOS7x has deprecated the AudioSession class in favour of AVAudioSession. Current v1.1 Quick-Jack library app is dependant on older AudioSession. This may not be directly contributing to the problem but worth noting as I would rather used the new one for future compatibility.

5) I found the white paper on HiJack and it indicates an increasing error rate as the baud rate increases (section 3.3). It mentions that reliable operation can be expected at ~8820 baud with bit error rate (BER) of 3.1x10(-5). This works out to about 2 byte errors in every 65,000 bytes transfered. NXP QuickJack is running at 1.4kbaud. It seems the posted library is already using a slower data rate. Not sure why this is but would expect an even lower BER for the slower 1.4Kbaud speed.
http://wiesel.ece.utah.edu/media/documents/pdf/2010/11/17/sigdev2010-final37.pdf

[lpcware]

Content originally posted in LPCWare by [email protected] on Tue Oct 28 12:52:00 MST 2014
Attached are the iOS Xcode5 debug logs for iPhone 4 verses iPod Touch 5G. The iPod and iPhone 5 yield similar errors so only iPod is attached.
•XcodeiPhone4DebugJoystick
•XcodeiPhone4DebugTemp
•XcodeiPodTouch5gDebugJoystick
•XcodeiPodTouch5gDebugTemp
•iPodTouch5gTemp.jpg

All tests performed on unmodified NXP Quick-Jack demo board (v3.0) and original source (v1.1). An extra debug at line 354 QuickJackApp.mm was added to display the received byte (ie: printf(“uartByteRx[%d]: 0x%x\n”, THIS.uartRecvNum, uartByte);). Both iPhone4 and iPod Touch 5G are running iOS 7.1.2.

Observations:

For the iPhone 4, all the functions of the Quick-Jack appear to work correctly (LED control, Joystick response, Temperature graph) and I do not see any ‘diff too long’ errors in reception during debug.

On the iPod and iPhone 5, the temperature graph can become unstable (ie: large swings in level). See attached photo of the iPod in Temperature mode. Both Temp and Joystick data reception is also showing ‘diff too long’ data errors.

Note1: I’ve also noticed that some byte patterns on the iPod yield the error and others do not. For example, the Joystick 0x1, 0x3, 0x5 byte do not show errors but 0x2, 0x4 do. It appears the errors are dependent on the bit pattern being transmitted.

Note2: Both the Joystick and Temperature demo functions are streaming data from board -> phone so they are ‘error’ tolerant. This means that although some of the data does not make it to the phone, it at least responds to the data that does make it. For the joystick, only a single byte is transported and is continuously sent while key is held. For temperature, a 4 byte pattern including the temp data is sent continuously while in the Temperature display mode. Erroneous data is more visible for the Temperature feature.