COMET USB Caller ID Setup Issue

V5 Question
41

If the V5 of this module is not much different than the V3 version, I have identified maybe the issue:
In class abstract class AbstractCidDevice : IDevice of the Samba.Addon.CalleridDevices.dll

 protected void ProcessPhoneNumber(string phoneNumber)
    {
        phoneNumber = phoneNumber.Trim();
        if (!string.IsNullOrEmpty(GetSettings().TrimChars ?? ""))
            GetSettings().TrimChars.ToList().ForEach(x => phoneNumber = phoneNumber.TrimStart(x));

==LOOK THE FOLLOWING LINE==
if (string.IsNullOrEmpty(phoneNumber)) return; <<= HERE WHERE THE CODE EXIT

        var thread = new Thread(() => _applicationState.MainDispatcher.Invoke(new Action(() => Process(phoneNumber))));
        thread.SetApartmentState(ApartmentState.STA);
        thread.Start();
    }

Since the message the module receive from MODEM is a SIMPLE MESSAGE (only date time and phone number), your code (https://github.com/emreeren/SambaPOS-3/blob/master/Samba.Modules.CidMonitor/CometDevice.cs#L123 ) do the ā€œelseā€ statement, skip the DATA packet and the PhoneNumber is NULL (or empty). So the Popup is Never Called.

I hope this may help you to identify the potential issue.
I hope also we can get a feedback from you and in case having a Patch of your code (in case you think there is an issue of course)

Thanks.

42

So here is my solution, tested properly on our system using the C# compiler.
Can you patch up your dll and send it over please ?

public CometData(int[] data)
        {
            const byte CALLER_ID_SDMF = 0x04;
            const byte CALLER_ID_MDMF = 0x80;

            // Check Caller ID packet id
            if (data[0] == CALLER_ID_MDMF)
            {
                  ......
            } else if(data[0] == CALLER_ID_SDMF){
                string number = "";
                int limit = data[1] + 2;                    // Add the 2 Initial Bytes
                int start = 10;                                // Skip The Date & Time Bytes 0|1|dd|mm|hh|mm
                for (int i = start; i < limit; i++)
                {
                    number += (char)data[i];
                }
                CIDNumber = number;
            } else {
                // THE ERROR ROUTINE !!!
            }
        }
43

Hmmā€¦ That code is what they release from their website. I though the driver formats data like that and should handle such line issues.

Can you enable logging for putty, call couple numbers and post the log file?

Pasted image904Ɨ838 36.9 KB

44

Here is my putty log entry:

=~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2016.10.31 16:00:34 =~=~=~=~=~=~=~=~=~=~=~=
103116000897790537J
103116010897790537J

The problem is that the Comet Website sample code is only MDMF and not for SDMF
Its expecting an object while SDMF is just one long alphanumeric string.
First Byte: Message type 0x04 for SDMF
Second Byte is Data Length: 18 in my case (dd|mm|hh|mm|10 digits phone number)
Second Byte is 17 when i use a Landline (9 digit number)
Third Byte onwards is what putty logged.

The last Byte (J) in this case seems to be a random character that i havenā€™t been able to decode, but its irrelevant to me as i already have the number.

I ran their sample code and got that ā€˜ERROR - Not a CID packet!!!ā€™
Then looking at it more carefully i realised its expecting an object and not a string. But SDMF are strings only.
So i modified that to work with my line. Next i opened up the SambaPOS Github file to see how you guys implemented and realized thats where the issue lies.

Anyways, you should at least put an else { ERROR } routine to notify in case of unexpected results. If SambaPOS had given me a notification like ā€˜CID message invalidā€™ then i would have known where to look 4 months ago.

PS: We are using V5.1.60 in case youā€™re planning to send the DLL over.

45

Sorry @digithai Iā€™m expecting the exact log file to be able to see full data. Iā€™ll be glad if you can zip and post it as a file.

46

Its literally the exact text in the fileā€¦

putty.zip (184 Bytes)

1 Like
47

I think this part is the exact data for a single call.

Pasted image1295Ɨ550 24.5 KB

How youā€™ve determined this constant?

const byte CALLER_ID_SDMF = 0x04;
48

I printed the HEX out for the first byte using a bit of modifications on the sample code from the distributor.

After checking the putty output and the data from the Code, one thing that was clear is that its a string and not an object. So that switch case would never work on this.

PS: Iā€™ve already provided a copy-paste solution, can you just patch the dll file and send me so i could test it before my day is over? You can test further as you like for your next version and i can let you know as well if my code worked at all. Because if i remember correctly you dont have the device for testing, and this issue seems location related as most countries use MDMF.

Reference:


Page 4

" There are currently three values defined
for the message type parameter of SDMF formatted packets. A packet
with a message type value of 0x04 contains the number of a calling
party, a value of 0x06 indicates a message waiting indicator packet, and
a value of 0x0B has been reserved for future applications. The next byte
in the header is the message length parameter. This parameter, as its
name suggests, contains the number of bytes of Caller ID data that
remain in a block."

49

@digithai I donā€™t think youā€™re listening me. Your code will not work with putty data youā€™ve provided. Whatever SDMF definition is data appears in putty log does not match to what youā€™re trying to explain. Do you have any idea why 0x0D appears instead of 0x04? If I release your fix like that Iā€™m afraid youā€™ll keep blaming on meā€¦

btw you should blame COMET for this. When a sample code released it expected to work with all cases. We canā€™t predict how it works for different cases.

Should I follow what appears on putty log or should I trust your solution will work and will not break existing working setups? Maybe hardware does not follow these standards ?

One more thingā€¦ Data was ending with > on your old putty screen shots. Now it ends with J. Did you changed drivers or did something like that?

50

Nothing to blame emre,

can you just patch the dll and send it over once so we can try it please?
u dont need to include my patch in your official releaseā€¦ Just let me try my code can we ?

As i mentioned before, the last byte seems to be a random character that i have not decoded yet, and dont need to as i already have what i need.

51

Sorry I disagree. COMET handle the DATA and SEND AS IT IS the packet to the serial port. Who is Listening to the Serial port? The Dll of SambaPos that handle the data and send the notification on screen. If you state that the code into the DLL is not your code but COMET staff code, then the source code of the dll should be free and we could modify and recompile the dll.

In the Market (as mentioned multiple times) there are 2 STANDARD DATA PACKETS. SMDL and MDMF. Are STANDARD FORMATS. We did not invent them. I sent also the reference document. Your DLL seems to handle only the MDMF. Reading the Data Format of SMDF and handle by the DLL should not be so difficoult. Please, we can discuss later who to blame or not, but we should work TOGETHER to find a solution to our issue with your components. Thanks so much.

52

Really? Hmmā€¦ OK. I understand it is my responsibility. It will work fine on next update.

Thanks.

53

Is it really that difficult to just patch a DLL and send it over?
already gave you the code, not asking you to add it to your official releaseā€¦

just one patch, copy-paste, compile, send it over, and then delete it from yours. U know we have already spent 4 months trying to solve this. can we be just a bit cooperative please?

54

Emre, I tried to contact you by phone (talked with tayfun I think) we really need this patch asap.

Ca we please have one of the 2 below ?
1)Could you please let us know when this ā€œnext releaseā€ will be released? Please a Date. So that we can tell our customer about your defect (not related to our code).
2) Can you be so gentle instead to provide only for us a hot patch that can let your code work fine with the Telephone line in Asia? Please try the patch we provided, if it does not work we roll back the original dll.

Letā€™s try to work as a team, we are professional developers as much as you and your great team.
Thanks for understanding.

55

Why the hostility? Emre doesnā€™t deserve that. We understand you need this to work and Emre said he will work on it so why are you more important than the rest of us? Please letā€™s be a little more respectful

56

Hostility? We are really not. Emre is an excellent developer and I would like to be collaborative to improve SambaPos.
We found the defect, we explained the issue, we provided the patch and we ask gentle to give us a solution or workaround. We are sure not more important than anyone, neither less also.
We were totally collaborative on investigating an issue (not our code), debugging, providing the details and solution.
If it seems we are hostile, we are giving a wrong impression. We are not. We just under pressure for a project that has a bug and do not depends on our code. BTW COMET team answered us that The Modem Works as expected well with Simple and Multiple messages data packet. Data are transmitted well on the serial port.
Honestly I do write code in C#, Java, and other languages since 1993 in international projects. I know the complexity of handle multiple versions of a code, make patches, and provide support. But creating a new branch of the DLL and make a patch a described, compile the DLL and send to us, was simpler than writing all this posts in the last 4 hours.
I am sorry if you think we are hostile. I can say sorry if you can feel it better.
Weā€™ll wait a solution at the issue at your convenient time, in the meantime we can develop a module as a workaround to display the CallerID data as expected, outside SambaPos. This will cost us extra development unpaid, because we suppose to use the paid software.
Thanks and sorry for this last long message. Better we keep coding.
Regards

57

@digithai, curious to know if you are aware that you can make your own device module DLLs for SambaPOS? If you do that, it will work inside SambaPOS.

Are you a member of Beta?

1 Like
58

Maybe we can (not aware of btw) , but why to create a component that duplicate a functionality that is already there but has a defect? Usually in these cases we just make a fix and deploy a patch. My idea would be to develop just a screen to display the caller id on screen. outside SambaPOS, I do not intend to write any code to substitute SambaPos functionalities. Would be a temporarily code (workaround) until the bug is not fixed. Thanks for telling me anyway. I am not member of beta, I sent months ago a mail to Emre to offer our skills as a develpment company to be part of the community. We never received any answer. Thanks.

59

My apologies then it seemed you were asking a lot from Emre and maybe word context was misused

1 Like
60

@digithai the problem is Iā€™m trying to help you but youā€™re ignoring me and want me to compile a dll to test your idea. Iā€™m working on .61 and I should roll back to .60 to be able to compile a .60 dll. I just tried to ensure it will work but you ignore that and keep explaining me SMDF (talking with @Tayfun, etcā€¦) . I setup virtual com ports on my pc, installed emulators and testing putty data to ensure if it works but it is not working with log youā€™ve provided. Iā€™m not getting the point of rolling back and compiling a non verified solution.

Pasted image2522Ɨ1512 345 KB

1 Like