Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - manfaiho

Pages: [1] 2 3 4
1
Hi all,

Sorry for my super busy in the past weeks no time update this thread! I took a whole day to dig into the coding (try and error) and finally identified the root cause then fix the issue. Yes, the data stream is sometime not consistent. It will even have NO data when all tags left out of home. If we assume no data then close the socket connection, the program will stop there and all tags will be departed after the timeout. Reader seems to use previous connected socket to keep the connection to send tag information. This is exactly my problem. I have changed the code especially for data stream handling below that can fix the problem eventually.

Code: [Select]
def handler(clientsock,addr):
        BUFFER_SIZE = 256
        while 1:
                try:
                        data = clientsock.recv(BUFFER_SIZE)
                        if not data: continue
                        if len(data)<8:continue
                        for i in range(0,int(len(data)/8)):
                                if data[i*8]!="\xFB" or data[i*8+1]!="\x10" or data[i*8+2]!="\x00" or data[i*8+3]!="\x00" or data[i*8+7]!="\x1F": continue
                                tagID =ord(data[i*8+4])
                                updateId(tagID)
                except clientsocket,e:
                        vc.triggerEvent("python.tcp.error",None)
                        continue
        clientsock.close()
        vc.triggerEvent("python.socket.thread.exit",None)

Of course, I have also added socketoption for timeout and created threading for each incoming socket connection for this infinite loop for recv(). Infinite looping for receving data stream is a key for Reader. If all tags not there, no data but we should wait there. Once any tags come back, the data should be continually received. It is different with so many traditional TCP server sample code whcih will close the socket then end when no data is received in buffer or specific key is treated as socket end. I attached the modified code for your reference. Enjoy!! Thanks all of your assitance and Happy VOXCOMMANDO :-)

Best regards,
Fai

2
I don't know why but it works on VOX. I am not familar with Python so I only know to use notepad for code modification. All logics are running as expect except TCP flow control which I never changed it. You can use your sample client to do the test and I am sure you shoulf get what you want. I have no clue for this sample so I decide to use "bridge" machine running TCP Plugin on VOX to handle all tag information from reader then copy back to another machine running on this sample for RFID alert. So far so good.

3
I used the attached code with 8 bytes TCP buffer where include a separate thread to trigger the initial arrival events within the initialization period, a loop to check every 8 bytes frame on single recv function if buffer size more than 8 bytes (of course, now is useless due to only 8 byte buffer size). Running it using bridge machine to redirect the tag information from the reader on this sample in separate machine, so far so good :-) I will continue to think how to direct recevie tag information from the reader using this sample. Update you all later....

4
Thank all of your assitance. Yes, it is hard to trouble if lack of reader for trial and error. I will continue to test then update you all. I think it is socket issue so I will go deep for this area....

5
Hi James,

Thanks, I used 256 as the buffer size and added 8 bytes buffer test before but no improvement. I also downloaded your script and re-test it. No improvement! Any clue?

Do you know what the difference of how to code TCP server between TCP Plug-in and your sample?

Best regards,
Fai

6
I'm so sorry for my late reply because I was recently super busy  >:(

Hi James and nime5ter,

I've tried different buffer sizes and added the logic to check if (1) less than 8 chars on the buffer, (2) its header and footer bytes even (3) the length of buffer to ensure looping every 8-byte frame within buffer to check TagID, in order to avoid any duty bytes or any length size of buffer but no improvement. I found the "blocking" on socket.recv function very often when this sample is just startup or runing a while so I strongly suspect the part of TCP server code from this sample may not be able to handle the pattern of this continuous requests from the reader.

However, I found an temp solution but it is not perfect. I setup one more VOX on another machine B as a "bridge" and configure TCP Server there to receive these requests from the reader then immediately use TCP.SingleWrite to copy this stream back to this PY sample running on machine A. It seems running very well. I found using TCP Server from VOX's TCP Plug-in on this "bridge" machine should be much more robust than that's running on this PY sample.

I am not familiar with TCP programming but I found more information from web to point me to use socket option to set non-blocking mode for recv function and should use a very special logic to handle unknown buffer size sending from client. BUt I don't know how to change the code. What I know is TCP Plug-in as bridge to this sample can resolve my case. Any idea and suggestion?

Best regards,
Fai

7
Hi James, I checked the logs and found TCP data stream may contain many tag information being detected from reader. That may be the reason why I have occasionally observed some tag suddently departure then immediately arrival. We may need to get the data using the concept of serial communication in TCP, byte by byte check to ensure every tag information within the predefined length of byte can be retrieved. Not sure if it is also the cause we crash the buffer in tcp sometime. Any idea, James? I attached the sample from manufacturer for your reference. They only detect the frquency of tag arrival instead of the logic of arrival and depature. It looks like the reader should have no concept of departure, just stop to report its infomation of tag which is not in-range right after.

8
Thanks, James. I install and run a while. I found all tags would suddently be departed simultaneously but this one is no tcp error. The log I see the last stream is just only FB then nothing else. All program stopped there. No tags are detected anyway. I need to restart it back to normal. It is different with before. Las time, once all were departed then I got TCP error then the program can be resumed and all tags can be detected automatically. Any clue?

I am thinking if something wrong in reader then it suddently sent only one byte: FB then nothing else but it can continue a normal stream. When the code trys to get the rest of bytes after FB then got buffer error. Should we check the stream length or exactly data pattern to ensure a complete stream? Every time I got this problem, it can resume normal when VOX app is fully restarted (not VC.FullRestart which will not work so it should crash internally). No idea?

9
Hi James,

I got the problem. I found suddently the arrvied tages are departure then trigger tcp.error then all of those tages are arrival again. Screen attached.


10
Hi James,

You are so funny  ;D You can speak in Chinese...wooo....wooo...

Yes, I will try and test it. Possibly I will give up BitVoicer very soon. Actually, Traditional Chinese is not a Cantonese so I need to check how to configure Windows to recognize Cantonese command first. Good start and really appreciate your walkthrough then show us on YouTube. You are so awersome  :biglaugh :biglaugh :biglaugh :biglaugh :biglaugh

Best regards,
Fai

11
Hi James, thank you very much  ;) You are so helpful.

I will test it and get back you the result.

However, I found one more issue. As it is a 2.4G RFID, I occasionally found unexpected signal comes from somewhere that accidently triggers the arrvial event then immedidately departure after its timeout. I am thinking if the code can be enhanced to add one more counter which can count how many times the Tag is continuous in the range, say continuous 2 or 3 times to confirm if it is valid or not. If the continuous 2 or 3 times for this tag in the range, it can normally trigger the arrival event in order to avoid fault alarm.

Best regards,
Fai

12
I am still using the code you post on the last (thread safe one to protect data). I think the code may really got the error somewhere that as you mention so that it quietly die. Nothing it can continue to do that's my case. No tag can be detected until I restart VOX.

13
I will use various methods to control Vera such as NFC, Logitect Remote Control, Android Tablet, iPod, Cantonese speech recongiztion using BitVoicer via USB to Arduino. I want to standardize the same voice response on each scene execution in Vera triggered by above methods. That's reason why I need TTS server to handle this from Vera.

For Chinese speech recongization especially for Cantonese language not Marandine language, it is hard to come with voice libary from Microsoft. I can find it from Maradine language when I install language pack and switch the whole UI to this language. I love BitVoicer becasue it don't need to do this OS configuration, just set what speech recongization language within BitVoicer then everything do for you even you are still running English version fo Windows. It should use Speech API to do all what we need within the app. So you see the difference. Yes TTS I can change it if the approriate library is installed that I can do it on Enligh version of Windows but it can speak in Cantonese. But for sppech recognizatio I can't do except I change it to Hong Kong version of Windows totally for VOX.

14
I think it may be the problem. When I found it can't properly detect the tags in and out, I click Full Restart VOX that can resolve the problem. All in-range tags can be detected normally. Anything I should do? Should we include exception handling on this code such as the logic like close all threads then create all new threads to listen and time watch it again that is same for Full Restart. Or generate more informaiton for debugging? 

15
Thanks, James. It works perfectly and resolved my problem. Actually, I setup this TTS Server using TCP Server running on VOX in order to speak any sentence received from TCP client such as Vera. Hence, I found VOX can't speak and recoginze Cantonese.

I actually installed BitVoicer to configre it to recongize Cantonese command then trigger it on VOX over TCP network (using VOX's TCP Server) to control Vera and use TTS to speak the response. (BitVoicer has no respsone or TTS feature) to simulate VOX Cantonese version. I don't know if it is a good solution but at least I can play Cantonese speech recongization with VOX and BitVoicer. In the old day, I used BitVoicer to command it using Arduino to trigger https to control Vera. Now I can use VOX to do the same with a new feature of Cantonese TTS response for each command :-)

Pages: [1] 2 3 4