TV Guide: This is a digital TV program for Tricolor TV, which is downloaded in real time via satellite. Therefore, sometimes it can take up to ten minutes to download the data. Possible error "No transmission data", or “There is no program guide on this channel or has not yet been downloaded... All this can lead to malfunctions in the receiver.
First you need to understand the reasons why the TV guide does not work:
- Incorrectly set time on the receiver itself;
- The equipment has malfunctioned;
- Outdated firmware or the receiver is broken;
Of course, you can't leave the equipment in this state, so you need to look for a solution. The simplest solution to the issue is to contact the specialist who installed your equipment. In addition, you can try to contact the Tricolor TV specialists by calling the hotline.
How to fix a TV guide on Tricolor TV
- Set the correct time on the receiver. To do this, press “menu” on the remote control of the receiver, then find the “date and time” section. Set the exact date and time;
- Reset settings to factory defaults. Instructions:;
- Try to update the receiver, perhaps an update has been released with new settings;
- Reboot the receiver. To do this, you need to do the following: turn it off. Then unplug its power cord for a few minutes. Turn on the receiver. Errors will be reset.
Do not expect the error with the TV guide to be resolved by itself. If you really need this function, then follow all the points of our instructions and the TV guide the program guide will work for each channel. Indeed, many subscribers face this problem.
Privacy agreement
and processing of personal data
1. General Provisions
1.1. This agreement on confidentiality and processing of personal data (hereinafter referred to as the Agreement) is freely accepted and of its own free will, applies to all information that LLC "Inseils Rus" and / or its affiliates, including all persons belonging to the same group with LLC "Inseils Rus" (including LLC "EKAM service") may receive information about the User while using any of the sites, services, services, computer programs, products or services of LLC "Inseils Rus" (hereinafter referred to as the Services) and the course of execution of any agreements and contracts with the User by Insales Rus LLC. The User's consent to the Agreement, expressed by him within the framework of relations with one of the listed persons, applies to all other listed persons.
1.2 Use of the Services means the User agrees with this Agreement and the terms and conditions specified therein; in case of disagreement with these conditions, the User must refrain from using the Services.
"Insails"- Limited Liability Company "Insales Rus", PSRN 1117746506514, INN 7714843760, KPP 771401001, registered at the address: 125319, Moscow, Akademika Ilyushin st., 4, building 1, office 11 (hereinafter - "Insales" ), on the one hand, and
"User" -
or individual possessing legal capacity and recognized as a participant in civil legal relations in accordance with the legislation of the Russian Federation;
or a legal entity registered in accordance with the legislation of the state of which such a person is a resident;
or an individual entrepreneur registered in accordance with the legislation of the state of which such a person is a resident;
which has accepted the terms of this Agreement.
1.4 For the purposes of this Agreement, the Parties have determined that confidential information is information of any nature (production, technical, economic, organizational and others), including the results of intellectual activity, as well as information about the methods of carrying out professional activities (including, but not limited to: information about products, works and services; information about technologies and research works; information about technical systems and hardware, including software elements; business forecasts and information about prospective purchases; requirements and specifications of specific partners and potential partners; information related to intellectual property, as well as plans and technologies related to all of the above) communicated by one party to the other in writing and / or electronic form, explicitly designated by the Party as its confidential information.
1.5. The purpose of this Agreement is to protect confidential information that the Parties will exchange during negotiations, concluding contracts and fulfilling obligations, as well as any other interaction (including, but not limited to, consulting, requesting and providing information, and performing other instructions).
2. Obligations of the Parties
2.1. The Parties agree to keep secret all confidential information received by one Party from the other Party during the interaction of the Parties, not to disclose, disclose, disclose or otherwise provide such information to any third party without the prior written permission of the other Party, with the exception of cases specified in the current legislation, when the provision of such information is the responsibility of the Parties.
2.2. Each of the Parties will take all necessary measures to protect confidential information at least using the same measures that the Party applies to protect its own confidential information. Access to confidential information is provided only to those employees of each of the Parties who reasonably need it to perform their official duties for the implementation of this Agreement.
2.3. The obligation to keep confidential information in secret is valid within the term of this Agreement, the license agreement for computer programs dated 01.12.2016, the agreement of accession to the license agreement for computer programs, agency and other agreements and for five years after termination their actions, unless the Parties separately agree otherwise.
(a) if the information provided has become publicly available without violating the obligations of one of the Parties;
(b) if the information provided has become known to the Party as a result of its own research, systematic observations or other activities carried out without the use of confidential information received from the other Party;
(c) if the information provided has been lawfully obtained from a third party without the obligation to keep it secret until it is provided by one of the Parties;
(d) if the information is provided at the written request of a state authority, other state authority, or local self-government body in order to perform their functions and its disclosure to these authorities is mandatory for the Party. In this case, the Party must immediately notify the other Party about the received request;
(e) if the information is provided to a third party with the consent of the Party, the information about which is being transferred.
2.5. Insales does not verify the accuracy of the information provided by the User and does not have the ability to assess his legal capacity.
2.6. The information that the User provides to Inseils when registering in the Services is not personal data, as they are defined in the Federal Law of the Russian Federation No. 152-ФЗ dated 07/27/2006. "About personal data".
2.7 Insales reserves the right to amend this Agreement. When changes are made, the date is indicated in the current edition last update... The new version of the Agreement comes into force from the moment it is posted, unless otherwise provided by the new version of the Agreement.
2.8. By accepting this Agreement, the User realizes and agrees that Inseils can send the User personalized messages and information (including but not limited to) to improve the quality of the Services, to develop new products, to create and send personal offers to the User, to inform the User about changes in Tariff plans and updates, to send the User marketing materials on the subject of the Services, to protect the Services and Users and for other purposes.
The user has the right to refuse to receive the above information by notifying this in writing to the address Email Insales -.
2.9. By accepting this Agreement, the User understands and agrees that the Inseils Services may use cookies, counters, other technologies to ensure the performance of the Services in general or their individual functions in particular, and the User has no claims against Inseils in this regard.
2.10. The user is aware that the equipment and software used by him to visit sites on the Internet may have the function of prohibiting operations with cookies (for any sites or for certain sites), as well as deleting previously received cookies.
Insails has the right to establish that the provision of a certain Service is possible only if the acceptance and receipt of cookies is permitted by the User.
2.11. The user is solely responsible for the security of the means chosen by him to access the account, and also independently ensures their confidentiality. The User is solely responsible for all actions (as well as their consequences) within or using the Services under the User's account, including cases of voluntary transfer of data by the User to access the User's account to third parties on any terms (including under contracts or agreements) ... At the same time, all actions within or using the Services under the User's account are considered to have been performed by the User himself, except for cases when the User has notified Inseils about unauthorized access to the Services using the User's account and / or about any violation (suspicions of violation) of the confidentiality of his account access means.
2.12 The User is obliged to immediately notify Insails about any case of unauthorized (not authorized by the User) access to the Services using the User's account and / or about any violation (suspicion of violation) of the confidentiality of his account access means. For security purposes, the User is obliged to independently carry out a safe shutdown under his account at the end of each session of work with the Services. Insales is not responsible for possible loss or damage to data, as well as other consequences of any nature that may occur due to violation by the User of the provisions of this part of the Agreement.
3.Responsibility of the Parties
3.1. A Party that has violated the obligations stipulated by the Agreement regarding the protection of confidential information transferred under the Agreement is obliged to compensate, at the request of the affected Party, for real damage caused by such a violation of the terms of the Agreement in accordance with the current legislation of the Russian Federation.
3.2 Compensation for damage does not terminate the obligations of the offending Party to properly fulfill its obligations under the Agreement.
4.Other provisions
4.1. All notifications, inquiries, requirements and other correspondence under this Agreement, including those that include confidential information, must be made in writing and delivered in person or by courier, or sent by e-mail to the addresses specified in the license agreement for computer programs dated 01.12.2016, the agreement of accession to the license agreement for computer programs and in this Agreement or other addresses that may be further indicated by the Party in writing.
4.2. If one or more provisions (conditions) of this Agreement are or become invalid, then this cannot serve as a reason for the termination of other provisions (conditions).
4.3 The law of the Russian Federation shall apply to this Agreement and the relationship between the User and Insales arising in connection with the application of the Agreement.
4.3. All suggestions or questions regarding this Agreement, the User has the right to send to the Inseils User Support Service or to the postal address: 107078, Moscow, st. Novoryazanskaya, 18, p. 11-12 Business Center "Stendhal" LLC "Inseils Rus".
Date of publication: 01.12.2016
Full name in Russian:
Limited Liability Company "Insales Rus"
Abbreviated name in Russian:
LLC "Insales Rus"
Name in English:
InSales Rus Limited Liability Company (InSales Rus LLC)
Legal address:
125319, Moscow, st. Academician Ilyushin, 4, building 1, office 11
Mailing address:
107078, Moscow, st. Novoryazanskaya, 18, p. 11-12, BC "Stendhal"
INN: 7714843760 Checkpoint: 771401001
Bank details:
In 2015, Tricolor TV has no free channels left.
If all your channels are encrypted, possibly showing First or NTV or Karusel or TNT, then you need to check the status of your subscription.
You can check the subscription to the single package through the Personal Account of the Tricolor TV subscriber.
Or on the Tricolor website, see how to do it.
Due to technical reasons, interruptions in signal reception at subscribers are possible, which are manifested in the coding of TV / radio channels of Tricolor TV.
If a problem occurs, you need to reboot the receiving equipment. If necessary, send reactivation commands via the personal account or by phone, which is below ..
Or call toll free number 8-800-500-0123 and ask the operator.
If there is no active subscription, you need to pay a single tariff of 1200 rubles per year.
The call is free.
Let's take a look at the most common reasons why Tricorlor TV does not show.
And let's try to establish our Tricolor.
1. First of all, let's see if the Tricolor channel shows us the information channel.
This channel should show, even if you remove the access card from the Tricolor receiver.
If you have this channel, go to step 2.
If it does not show the inscription No signal on the screen.
Perhaps you have lost the settings of your receiver.
Then go to the settings and do a factory reset.
After the reset, we look to see if your receiver sees the quality and signal strength, if it does, it should find the channels for you and start showing.
If the receiver does not see the signal, then the problem lies elsewhere.
The problem may be in the Tricolor receiver, in the dish tuning or in the converter.
To solve this problem, you need to call the installer.
Or you can customize the tricolor plate yourself according to THIS instructions.
2. If it shows the channel's infor, and the free tricolor channels from the basic package are not shown, then you have not confirmed the subscriber's data in Tricolor TV or our receiver does not see the card, or the card is installed on the wrong side.
How to confirm the personal data of a subscriber
To see if your receiver sees the card, we go to the menu - conditional access - DRE module - information about the smart card and in the ID card item there should be a number that is written on your Tricolor card installed in the receiver.
This is an example for a tricolor GS 8300N receiver, for other general satellite receiver models the path to the ID card may wake up a little different.
If your receiver does not see the card, take it to the service or check the card on another Tricolor receiver.
3. If you only have free channels, your subscription may have run out.
If you know for sure that the subscription has not ended yet, then you need to re-link your equipment to the Tricolor satellite.
To do this, you need to call +7 800 500-01-23 and ask the operator to send a reactivation signal.
Or write to the mail z request to repeat activation commands - This email address is being protected from spambots. You need JavaScript enabled to view it.
According to the tricolor, the image should wake up no later than eight hours later.
From experience I can say that decoding takes about 30-60 minutes.
4. Do not show HD channels Tricolor, but you definitely have a receiver with HD support?
I have considered the most common reasons why Tricolor TV does not work.
If you have any questions or additions, write in the comments.
In the first lines of my textual expression I want to say the following: Much has already been written about this, and I will write my vision too. Standard interfaces for transferring information are great, but for my needs they do not sufficiently provide all-satisfactory (or almost) data transfer. I will try to make some additions in order to bring it to the state that suits me.
There are 2 or more devices at a sufficiently large (1-100 meters) distance between which data must be transmitted. Having examined some interfaces (rs232 / 422/485, I2C, Ethernet) I came to the conclusion that they either do not guarantee unambiguous data transfer, I did not like a lot of wires either, they do not give an answer that the information was received. I decided to take the RS485 interface as a basis - from its advantages it can "go far", 2 wires, you can connect a bunch of devices at the same time, it's simple, (UART) is available on almost any controller.
In my case, the classic scheme 1 master is suitable for me, the rest of the slaves. The messaging algorithm is as follows: data transfer occurs in exchange cycles, one exchange cycle consists of a message that is transmitted from the master to the slave, in response the master receives a message from the slave, all others are silent. On the same basis, implement a request to receive data from a slave device.
One exchange cycle.
There are only two issues that need to be addressed to meet my data communication needs. Question one: the check of the transmitted byte is based on the RS-485 interface itself, but it does not guarantee a reliably transmitted byte - when a corrupted byte is found in the interface itself, it is thrown out of the received data, but at the same time it still remains possible to transmit an incorrect byte - if it has changed (corrupted ) an even number of bits in a byte. those. a check is required for the number of transmitted bytes and the validity of the bytes in the transmitted data.
Question two: receiving a response message to the transmitted one.
On the first question: the following scheme is proposed: starting byte, quantity byte
transmitted characters in the whole message, something else, bytes checksum(BCS), end byte.
Note: read the checksum byte modulo 2
Based on the proposed scheme, it can be judged that if the answer did not return, then the slave is not available. In this case, variants are possible when a corrupted message reaches the slave and he does not respond to it, or the message reaches him and he sends a response, but the response is spoiled and the leader ignores it.
To correct this, it was accepted: if the answer does not come (or comes but is unreliable), then repeat the current exchange cycle (number of times without insanity). Here may arise next error... Let's say we send a command to the speaking device to increase the volume by +1 unit. When the message reaches the slave, he executes the command to turn up the volume and sends the response "ok, I did as you wanted", while it may turn out that the answer gets corrupted and the master does not understand that the command has already been executed, and sends the message again. As a result, upon receiving a command on the slave side, the volume will already be increased by +2 units. To avoid such a phenomenon, it is customary to introduce an identifier (NS - message number) of message differences. If the message number is repeated, then this is a repeated message and the specified command does not need to be executed, but simply send the previous response message.
Also, here I enter 2 more parameters - this is the number (code) of the device to which the data is transmitted and the number (subcode) indicating which command should be executed (or what data is inside the message).
As a result, I will add everything together and go through the algorithm, using the example of increasing the value of the relay triggering threshold for temperature by 5 degrees Celsius and taking the current temperature reading from the slave device for 1 exchange cycle:
I form the transmitted data from the master:
When a message is received, the slave looks at 2 bytes, where is the number of bytes sent, if the number of bytes sent is equal to the number of received ones, then the message has not lost bytes. Then we look at the start byte (character) if it = "$", as well as the end byte (character) if it = "#" - then this is a message from the master to the slave.
I will immediately consider possible options messages from master to slave with errors in the start and end bytes, as well as a variant with an error in the number of bytes in the message. I will make a reservation at once from 3 values of parameters I will consider 2 and 3 to be correct, i.e. if 2 parameters out of 3 possible coincide, I consider the message to be valid.
1. start byte = "$", number of bytes received = 7 (number of bytes sent = 7), end byte is not equal to "#";
2. start byte is not equal to "$", number of bytes received = 7 (number of bytes sent = 7), end byte = "#";
3. start byte = "$", number of bytes received = 7 (number of bytes sent = 7, number of bytes is not equal to 7), end byte = "#".
Next, we calculate the checksum of the remaining 3 bytes (bytes 3, 4, 5), if it matches the BCS, we continue parsing the data, we look for this device for this data and what needs to be done on it, in our case the slave device code is 55 and the subcode 2 says that it is necessary to add another 5 degrees to the threshold of the relay and send the current temperature data in a response message. I check the NS if it is not equal to the previous message number, then I execute the command and add 5 degrees to the current value of the relay threshold. If they are equal (NS), then I do not perform the indicated actions, then I proceed to the formation of a response message.
The use of the scheme ["$"] [number of bytes sent / received] [...] ["#"] - with a high probability guarantees that such a combination will not be able to occur in the transmitted data, and provoke a false message.
I form the transmitted data from the slave based on the received message:
The processing principle is as follows: look at 2 bytes where the number of bytes sent is located, if the number of bytes sent is equal to the number of bytes received and also the start byte = "@" and the end byte = "&" - then this is a message from the slave to the master. If required, I use the 2 of 3 mechanism, similar to the one described above, only for the response message (for the symbols "@" and "&"). When receiving this message, the master analyzes the checksum of 9 (from 3rd to 11th) bytes, if the checksum matches, the data in the message is considered reliable and further data analysis continues. If the code, subcode and NS of the sent and received message match, we continue to analyze the response to the message sent by the presenter. Next comes the analysis of the received data, in my case in the 6th byte value 1 - indicates that the command to add 5 degrees to the relay operation threshold was successful, the remaining 5 bytes indicate the current temperature readings 7th byte - a flag indicating reliability the transmitted temperature (i.e. I am considering the option the slave device is turned on and responds, but the sensor may not work) and 4 bytes of float type temperature values.
The use of 2 check characters at the beginning and at the end of the message most likely guarantees that in case of an error, the messages from the slave and the master will not be confused. Also, random (not random) data in the channel will not spoil the exchange.
A bit about transferring data from slave to slave, and a centralized message to all slaves from the master.
First, about the latter - the transmission from the master to the slave is carried out by assigning a device code 255, telling the slave that this is a centralized message, then it remains only to decide the issue of common subcodes, you can also group by device codes, i.e. assign the device code 254 and according to this code 3 or 4 devices will receive the message, the rest ignore it, of course, the part on sending responses from the slave devices should not work here - i.e. it is not guaranteed that the slaves will unambiguously accept these messages!
On the transfer of data from the slave to the slave, the master sends a message to the slave (slave1) from which information should be received to the slave (slave2), slave1 sends a response to the master, while slave2 eavesdrops on this response, taking the data for himself. Again, there is no guarantee of unambiguous message delivery from slave1 to slave2, this must be taken into account!
Interface capabilities number of theoretically connected devices about 250, commands / data types up to 248 for each device, length useful information in a message up to 250 bytes.
Let's talk about the pitfalls:
All data transfers are timed, i.e. certain delays between messages should be observed. I also recommend making a fixed delay between the sent message of the master and the response of the slave so that the slave has time to generate data and completely send it to the channel.
The moment of organizing responses from the slave is also important, it may happen that the slave was busy and had data from several messages in his channel at once, you should avoid replies to obsolete messages (because the master is no longer waiting for them), ignoring them, executing the commands of only the last actual one messages and respond to it.
Separately, I would like to highlight the issue of synchronizing devices in time - it should be borne in mind that time synchronization of the slave when receiving a message requires taking into account the time delays for sending data to the channel (at a speed of 9600, a 10 byte message will be transmitted about 11 ms) and the moment when the interrupt is triggered is important at the end data reception on the slave side, if there is no interrupt, then it is worth considering the time of checking the arrival of data in the device buffer, etc.
It is also worth noting that re-sending the message cycle also adds nuances, I recommend using sending a message without repetitions for time synchronization, and generating messages with a new NS.
P.S. I have doubts that I discovered something new here, all of this is used to one degree or another somewhere in different interfaces! With the light hand of the author of this scribble and the use of this protocol in my developments, I want to give the name to this data transfer protocol "SRDB2".