TPS300B Connectivity Stability

[niiokaiaryee]

Hi Ibroheem, First of all let me say thanks for the sample code you posted on the TPS300 device. Your documentation, need i say, is better than what the manufacturer provided with the SDK.

I have this peculiar problem with connections timing out after a certain time on the POS. I looked at how you did your libs and modeled mine after same even though i maintained most of my code in C.

I noticed that if and when i put continuous pings from the server to the POS SIM, the connection never times out even when the POS is idle. When i do not, the connection times out a little after 15 mins.

Do you have any tips to give regarding connection stability...?

Additionally i have two POS terminal, one prints without breaks the other requires some code tweaks to make printing happen smoothly. Things is they are both TPS300B. Spoke to the tech team of the manufacturers sometime back last year and they passed on some drivers libs to me.

Would be grateful if you could share some tips if any on experiences you had with printing on the POS

Thanks in advance.

Nii.

[ibroheem]

1. Regarding the Network, I looked at my code again and found I always had to connect or at least check status for every transaction. I do disconnect from the server after each transaction tho. Some things are not stable with the device.

I'll do a GPRS connect, then TCP connect. When done, do a TCP disconnect.

2. As for the Printing, that other device is probably defective. You can look at the print.h file I just pushed.

TP_PrnSessionStart();
TP_PrnIndentSet(75);
TP_PrnLogo(You_logo_in_C_array, 216, 208);
TP_PrnIndentSet(0);
printer_o.add_newlines(2);
printer_o.print();

// Clear Print Buffer
printer_o.clear_str();

// Prepare for another Print
printer_o.add_string((uchar*)"       %s", (uchar*)trsn_code);

printer_o.add_newlines(6);
printer_o.print();
TP_PrnSessionEnd();

[niiokaiaryee]

Thanks very much. That was very helpful.

I noticed that it took quite some time to reconnect the GPRS after every transaction even though that method ensured server connectivity every single time.

If I may ask, have you tried pinging the server from the POS to keep the GPRS connection active?

Do you know anyway by which one can reduce GPRS setup time?

Thanks in advance.

Nii.

[ibroheem]

Sadly, I don't have the device setup any longer. I decided to just put my findings (half-arsedly) on Github perhaps it might be useful to someone. I've not worked on it since 2017.

[niiokaiaryee]

That's ok. Thanks for your help. Very much appreciated.

[niiokaiaryee]

Come to think of it, I checked the GPRS status every single time before I initiated a tcp connection request to the server.

The response I get is GPRS success Strangely enough when I tried ICMP request from the server to the same POS that gives GPRS success, timeouts is all I receive. To further confirm, I initiate a TCP connection to the server and get error -57

The GPRS connection breaks yet the POS is still under the impression there is a GPRS connection up. The only thing I have not checked for is an IP address still assigin to the PPP connection under those circumstances.

Beginning to think the hardware is playing up.

Will check and share my finding.

[ibroheem]

Those devices can be defective at times.

• Are u sure it's connected when u check GPRS conn? I make the connection itself before using TCP

• And What does -57 mean ?

• Were u able to fix the printer ?

[niiokaiaryee]

Error -57 means client is disconnected from the server.

Very sure about the response I get when I check the GPRS connection status. The response is very misleading.

Plus before I sent the query to you, I didn't disconnect the GPRS connection on every request. I just left it to run. I just reconnected the TCP connection as and when needed.

The device doesn't show consistent behaviour.

Still working on the printing as we speak.

[ibroheem]

When I want to send to server:

      if (gprs_network.connect()
          || network::status_w_code() == SRVCSTATUS_REGISTERED)
      {
         if (enable_ui)
         {
            TP_ScrGotoxyEx(37, 45);
            draw_bar_term_init_xy(rect, false);
         }

         bool b = server.connect_default_tcp();
         uint8 rtry = 0;

         estr::set_null(err_buf, _64B);

         while ((b || !b) && rtry++ < 2)
         {
            if(server.send(server.request<uchar>()))
            {
               if (!enable_ui)
                  timer::start_ms(500);
               ui::send(enable_ui);
               estr::set_null(buf_http_response, sizeof buf_http_response);
               if(server.receive(buf_http_response))
               {
                  ui::recv(enable_ui);
                  response_body((char*)buf_http_response, json_body);
                  TP_ScrRestore(0);
                  //TP_ShowTextFullScr(&display_info, (uchar*)"res: %s", buf_http_response);
                  TP_ScrRestore(1);
                  server.disconnect();
                  return true;
               }
            }
            server.disconnect();

            gprs_network.connect();
            b = server.connect_default_tcp();
         }
      }
///gprs_network.disconnect();

I also remembered doing ///gprs_network.disconnect(); for some reason.

[ibroheem]

The device doesn't show consistent behaviour.

Welcome!

[niiokaiaryee]

The device doesn't show consistent behaviour.

Welcome!

The main problem I have with the printing is with the barcode.

For some strange reason on a certain batch of terminals the printing breaks when the amount of chars exceed a number. The barcode doesn't print after. On another batch everything seems fine.

What I did as a work around was to init the printer just before the barcode printing by putting that section till the end of the slip in another session.

That's rough and dirty and puts a pause in the printing.

I don't know if you had any issue like that when you worked with the POS.

The networking seems fine now. I am observing for a while. I just hope that's it with the networking.

Another thing I noticed, at certain times or points in the use of the terminal, same just reboots. I am thinking that's the device's way of dealing with access violations. Any tips on that?