Sorry but im going to have to disagree with most of the other 'yes you can' answers and say that:
I would discourage a class calling one public method from another
There are a couple of potential issues with this practice.
1: Infinite loop in inhertited class
So your base class calls method1 from method2 but then you, or someone else, inherits from it and hides method1 with a new method which calls method2.
2: Events, Logging etc.
eg I have a method Add1 which fires an event '1 added!' I probably don't want the Add10 method to raise that event, write to a log or whatever, ten times.
3: threading and other deadlocks
Eg InsertComplexData opens a db connection, starts a transaction, locks a table, Then calls InsertSimpleData, with opens a connection, starts a transaction, waits for the table to be unlocked....
I'm sure there are more reasons, one of the other answer touched on 'you edit method1 and are surprised method2 starts behaving differently'
Generaly if you have two public methods which share code, its better to make them both call a private method rather than one call the other.
Lets expand on the specific case in the OP.
we dont have a lot of detail but we know that ReverseData is called by an event handler of some kind as well as the ScheduleTransmission method.
I asume that reverse data also changes the internal state of the object
Given this case I would think that thread saftey would be important and hence my third objection to the practice applies.
To make ReverseData thread safe you can add a lock. But if ScheduleTransmission also needs to be thread safe you will want share the same lock.
The easiest way of doing this is to move the ReverseData code into a private method and have both public methods call it. You can then put the lock statement in the Public Methods and share a lock object.
Obviously you can argue "that will never happen!" or "I could program the lock another way" but the point about good coding practice is to structure your code well in the first place.
In academic terms I would say this violates the L in solid. Public methods are more than just publicly accesible. They are also modifiable by its inheritors. Your code should be closed for modification which means you have to think about what work you do in both public and protected methods.
Heres another one : You also potentialy violate DDD. If your object is a domain object its public methods should be Domain terms which mean something to the business. In this case its very unlikely that 'buy a dozen eggs' is the same as 'buy 1 egg 12 times' even if it starts off that way.