Orchid V4, V4+ Programing Tool Support

Heinz

You lost me slightly there. Your idea is to make Kevin's spreadsheet usable by those without a modem by somehow making it generate DTMF tones itself?

Surely, even assuming there is a way to do that, simply make the necessary number of key presses on the telephone keypad would be easier and far more efficient than holding the telephone mouthpiece to the PC's loudspeakers to pass the DTMF tones to the Orchid?

apwood

Yes, that's what I mean. But if all the codes can be sent (including resetting to dial tone if possible), then a person could use the spreadsheet in exactly the same was as if they had a modem, with the small exception that instead of connecting the PC to the dialler (using a modem cable), they would "connect" the PC to the handset by simply placing the handset near the loudspeaker on the PC / laptop. Other than that, they could go and make a cup of tea or something whilst it goes through all the codes.

If they are only updating a single code or two, then the manual method would be easier of course. If they are updating several codes, then an automated method like this would not only be easier it would avoid people mistakenly dialling the wrong digits or codes.

apwood

After using the tool yesterday, I today found some calls failed to work correctly. Thought I'd post what I learned in case it helps others.

As background, I have no details of my originally programmed routing, and given the fact that the Heinz program would be an improvement, I decided to start again and update the whole of the carrier code and routing code tables on my dialler.

I firstly updated the off-peak times (they had changed when Pipex took over from Toucan) and reset the clock. I then used the green buttons to "Dial Carrier Code Table" (8 entries) and "Dial Routing Tables" (27 entries).

Following this update I found that:-

1. A local phone number was dialled incorrectly (it actually routed to directory enquiries). This was fixed by using the "Advanced" button and selecting "Clear Routing Table" and "Clear Carrier Table". On pressing "Write Settings" it cleared and then dialled the carrier code and routing code tables - great! My conclusion is that the routing code table that I was replacing must have had more than 27 entries, and the additional entries matched the number dialled and routed it to option 2 (which in the new carrier code table was for directory enquiries).

Doesn't this mean it would be safest for the "Dial Carrier Code Table" and "Dial Routing Table" buttons to automatically clear the tables first? (I assume these buttons always write the full table?)

2. My call plan includes free calls to other people who subscribe to the same telephone operator (Pipex ex-Toucan). However, such calls were now being routed via 18185, so they cost 5p instead of free. This was fixed by adding new entries to the routing code table for each friend's number with Handling Code A and Carrier Code 0 for Day, Night and Weekend.

Edit: Just received my original routing tables from Maggie at Orchid Electronics. It actually had similar entries to my "fix" above, but Handling Code E (exclusion) instead of A. E is defined as "Calls that will be routed to your line provider", so it is perhaps more appropriate, although A seems to work just as well!

3. We needed to phone our doctor's surgery (0845). Because they are always engaged, we tried to press 5 for "Ringback when free". This failed. Reason is that the routing (via 18185) was using 08081703703 (carrier code 5) instead of 18185 (carrier code 1). This routing is correct because the 0808 access is cheaper for daytime calls.

The routing was set to 5 (day), 5 (night), 1 (weekend).
(Instead of 5, 5, 3 in the original Heinz plan - 3 being 1280).

I could have fixed this by changing the routing to 1, 1, 1. But since we rarely use ringback other than for the doctor's surgery, I did this:

a) Set routing to 5, 1, 1 since this is just as cheap as 5, 5, 1 and limits the calls for which ringback would not work. Perhaps this change should be added into the main spreadsheet / Heinz plan - ie 5, 1, 3?

b) added a new entry to the routing code table for the full 0845 number with Handling Code A and routing 1, 1, 1 (If I had free 0845 weekend calls this would have been 1, 1, 3)


4. One further thought. My line rental is with Pipex, I don't benefit from any cheaper calls via BT, nor do I need to ensure some calls are routed via BT, so I have had to amend the spreadsheet significantly. To help other people in a similar position, should I upload a revised spreadsheet designed for them? If so, how would I do this, and could someone check it for me?

Hope this helps someone.

Dog_Watch

"First off, many thanks to Heinz, Kevin and many others - I used the programming tool for the first time in two years (absence from BT), replacing all the tables, setting the time of day and off-peak times. Everything worked really well utilizing my old laptop for its modem."
In the tables we're given codes to avoid Guernsey and Jersey (though not the Isle of Man) land lines. As I have a Jersey SIM for use abroad with Sim4Travel I've discovered the high costs of phoning it in the past. Should not, therefore, the codes for those islands' mobiles be excluded too? I have a list from OFTEL if required.

Heinz

Welcome to the MSE forums Dog Watch.

The use of 18185 for Channels Islands calls was one of the 19-2-1008 changes to the program as a result of BT publishing the fact that such calls were specifically excluded from their new call plans.

I don't remember them mentioning the Isle of Man too but, if the same is the case with those, you're right and a new rule to similarly route 01624 calls should be added.

Quentin

A question about making a manual change:

I want to change one rule, and am inputting the code for the change via my handset.

But nothing is changing.

Do I need to delete the original rule first? If so, how do you do that, please?

Victor_Delta

Heinz wrote: »

...I don't remember them mentioning the Isle of Man too but, if the same is the case with those, you're right and a new rule to similarly route 01642 calls should be added.

Heinz

I'm not sure that's what Dog Watch is suggesting. In any case, as far as I can see, BT's terms and conditions indicate that calls to the Isle of Man are treated as normal 01 calls.

V

PS Actually 01624 I believe... (01642 Middlesbrough area)

Heinz

Quentin wrote: »

A question about making a manual change:

I want to change one rule, and am inputting the code for the change via my handset.

But nothing is changing.

Do I need to delete the original rule first? If so, how do you do that, please?

You should be able to overwrite a rule (as you are doing).

As mentioned in post #111, Routing Rules 13, 14 & 17 are unnecessary and can be used for 'new' rules. However, if you wish to change another rule, overwriting is the way.

Quentin

Thanks, Heinz. I'll keep trying!

KevinLawry

Heinz wrote: »

First. There seems to be a problem with the tool in that it will only accept 8 Carrier Codes. The 9th does not generate a Programming Code (which was easy to fix) but the Routing Table then gives an "Invalid Carrier Code" error message when trying to put in Carrier 9. Is this a deliberate restriction in the tool?
CW Client used to come up with a checksum error when a Carrier 9 was added - which was why only 8 Carriers were allowed. I expect Kevin can answer (or fix) the "Invalid Carrier Code" problem with his table though.

:exclamati I have re-checked my reference material and programming notes, carrier code 9 is disabled because in the programming guide it is marked

Do not use

The emphasis on not is theirs not mine. With that in mind I shall leave that behaviour as is, anyone who wants to change it can do so but I can only assume that there was a good reason for the warning in the manual programming guide :exclamati

Sorry guys, I've been tied up with my paying job and not had chance to come here for a while - I'll make the programming changes soon - looking at some of the other things that have cropped up while I was away

I have looked at the idea of sending dtmf tones from the speaker before now as suggested by apwood, I have not found a way that I am comfortable with but I will look at it again because I can see some benefit (I have discussed the idea here before trying to help someone else) but I do not want to compromise the main application.

I am happy to leave the current behaviour where you need to explicitly delete the routing tables rather than have it happen by default.

Overall, I am not as clever with choosing routing plans as Heinz - I have taken out rules 13,14 and 17 that he has identified as surplus, I will leave the rest alone unless a consensus emerges on a suitable replacment - I do not have time to maintain more than one version so the more general the better and you guys can alter things to suit your particular needs.

I'll try & get the new version uploaded over the weekend