The DIAG port is a tap on the async comms between the PIC and the MODEM. During INIT, the PIC uses ATE0 to disable echo. This is necessary because if we receive SMS commands or GPRS data while transmitting a command (with echo on), things get confused - by turning echo off for production we don't get any such problems. I really wish the SIMCOM modem had a 'print' style AT command - something to just print out what it is given, but I can't find any such facility. The approach you use, for development, is fine. An alternative is to extend the SETUP mode in the code (see diag.c) to give you a similar facility. That can run with ATE1 no problem, as no modem comms are used. To get the module into SETUP mode, the following video should help: http://www.youtube.com/watch?v=-24PoWtHVzk Regards, Mark. On 3 Nov, 2012, at 3:35 AM, Michael Balzer <dexter@expeedo.de> wrote:
I wanted to get some direct debug logging. It took me some time to figure out the diag port only echoes what is sent from the SIM908 to the PIC18, I first thought it tapped RX+TX so I could see the complete communication.
Next problem was the modem switches echos off (after COPS I think), so I need to re-enable them at least once in a while.
I'm now using this scheme in can_state_ticker1():
#ifdef OVMS_DEBUG // CAN debug log via DIAG port SIM908 command echo: // ATT: could be a problem for running data transfers, // should not be enabled for production/live firmware images! net_puts_rom( "ATE1\r" ); sprintf( net_scratchpad, (rom far char*) "# ERR=%u SOC=%u RNG=%u SPD=%d PWR=%d CHG=%u\r", RXERRCNT, can_soc, can_range, can_speed, can_power, car_chargestate ); net_puts_ram( net_scratchpad ); #endif
My questions: am I right with the suspected problem, and is there a better way?
Regards, Michael
-- Michael Balzer * Paradestr. 8 * D-42107 Wuppertal Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
<dexter.vcf>_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev